pod
Other formats agents might prefer:
markdownjsonllms.txt

Agent? You probably want markdown or json, or Pod over MCP.

Reported issues for FocusRelay

Pod holds 22 of 92 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to FocusRelay.

Most discussed

Research and add discoverable MCP workflow prompts for OmniFocus

Current bounded delivery (2026-08-14)

The active implementation slice is intentionally narrower than the original research program:

  • refine the already-shipped process_inbox workflow with GTD-informed clarification;
  • carry forward the conservative ambiguity and bounded batch-lookup rules from OpenCode UAT;
  • expose the exact same workflow definition through a compact CLI retrieval command;
  • preserve the nine-tool MCP catalog and add no additional prompts.

Validation impact: `server-wi

Read the thread · 2026-07-14 · closed · 12 comments

Date fields cause timeout/crash on tasks with repeat schedules

Description When requesting any date field (dueDate, completionDate, plannedDate) via list_tasks, the bridge crashes with a date parsing error if any task in the result set has a repeating schedule. Error message Bridge response timed out after 45.0s lastReadError=dataCorrupted: Expected date string to be ISO8601-formatted. The error consistently occurs at a specific array index (e.g. Index 2) corresponding to a repeating task in the result set. Steps to reproduce

Have at least one repeating ta

Read the thread · 2026-04-06 · closed · external user · 11 comments

Spike: revisit multi-host transport decision — TCC diagnosis and Developer ID signing feasibility

User outcome

A Claude Desktop (or other desktop-app-hosted MCP client) user gets either a documented, supported FocusRelay setup path, or a documented, evidence-backed "not supported yet" with a tracked follow-up — instead of a silent bridge timeout. The spike's deliverable is a decision, not code: an updated transport decision document and, if warranted, a follow-up implementation issue.

Validation impact

docs — the spike produces diagnostic evidence and an updated decision document

Read the thread · 2026-08-01 · open · 6 comments

Release FocusRelay v0.12.0-beta: reliable inbox workflows

Release outcome

Ship a beta that makes inbox processing noticeably more reliable: users can start a guided inbox workflow, receive clear bounded results, and avoid parallel Bridge failures or leftover FocusRelay processes when their MCP client restarts.

Version

v0.12.0-beta

This is a minor beta because it adds a public MCP prompt and parent-aware tag discovery, changes the supported macOS baseline, and introduces a new process-wide Bridge execution architecture.

Validation impact

Read the thread · 2026-07-28 · closed · 6 comments

P2: Repair or remove the stale checked-in Homebrew formula

Severity

P2 release blocker: installation/packaging correctness.

Confirmed failure mode

homebrew/focus-relay-mcp.rb currently points to:

  • release v0.9.0-beta
  • archive name focus-relay-mcp-0.9.0-beta.tar.gz
  • SHA256 e3b0c442..., the checksum of an empty file

The formula installs a focusrelay binary that does not match the referenced archive naming. If a user or maintainer treats this checked-in formula as authoritative, installation cannot be trusted.

The external `deverma

Read the thread · 2026-07-13 · closed · 4 comments

Implement move_projects for Homogeneous Bulk Folder Moves

Summary

Implement move_projects / focusrelay move-projects for homogeneous bulk project moves between folders/sections.

This tool owns structural project relocation and keeps folder moves out of project patch tools.

Scope

Supported v1 destinations:

  • a folder by ID
  • the root library (no folder)

Supported v1 placement:

  • beginning
  • ending
  • default to ending

Out of scope:

  • creating folders as part of the move
  • name-based destination lookup
  • mixed destination payloads

Read the thread · 2026-04-17 · closed · 4 comments

Prototype an instruction-first process_inbox MCP prompt

Parent discovery issue: #94

User outcome

Let users discover and start one safe inbox-processing workflow through the MCP prompt protocol without adding another public tool or embedding their OmniFocus library in the prompt response.

Bounded outcome

Implement the smallest instruction-first prompt vertical slice:

  • advertise MCP prompt capability;
  • return exactly one prototype from prompts/list: process_inbox;
  • return a compact, model-neutral instruction template from `prompts/get

Read the thread · 2026-07-26 · closed · 3 comments

Support dropping and restoring OmniFocus tasks without recording completion

User outcome

Let a user discard an unwanted OmniFocus task without recording it as completed.

Today FocusRelay can complete or reactivate a task but cannot express OmniFocus's distinct dropped state. An assistant therefore has no correct write available for requests such as "drop one of these duplicate inbox tasks." Completing the item is not an acceptable fallback because it records work that was not done.

Validation impact and dependencies

  • Validation impact: mutation
  • Depends on

Read the thread · 2026-07-18 · closed · 3 comments

Most recent

Make benchmark timeout diagnostics passive before v0.13 retry

Outcome

Make benchmark timeout diagnostics passive before the v0.13 retry so observing a timeout cannot add Bridge requests during recovery.

Scope

  • Capture queue and process state immediately when a benchmark call fails.
  • Remove diagnostic Bridge health requests and the undocumented recovery-delay environment behavior.
  • Preserve the effective passive wait: 13,000 ms by default and for smoke/stress; 15,000 ms for release.
  • Do not change production transport, BridgeClient, plugin, MCP

Read the thread · 2026-08-18 · open · 1 comment

Guide MCP clients to serialize FocusRelay reads and triage bounded slices

Scheduling

Post-release backlog. Do not start this work or change the frozen release candidate until the current release verification is complete.

User outcome

When a supported MCP client asks FocusRelay to review a large due or flagged workload, it processes one bounded slice at a time instead of launching overlapping Bridge reads or falling back to another OmniFocus server.

Validation impact

server-wire — this changes the MCP Initialize instructions visible to clients, not quer

Read the thread · 2026-08-17 · open · 0 comments

Clarify the IPC spec's cross-process admission contract

User outcome

A maintainer reading the IPC specification can tell exactly which concurrency guarantees apply inside one FocusRelay process and which behavior remains unvalidated across several client-spawned server processes.

Validation impact

docs

User-facing acceptance journey

  1. A maintainer investigates several terminal MCP clients using FocusRelay on one Mac.
  2. They read IPC-SPEC.md and see that the Bridge FIFO is process-wide, not a machine-wide or cross-process loc

Read the thread · 2026-08-12 · closed · 0 comments

Measure cross-process Bridge admission across concurrent terminal MCP clients

Parent context

  • #170 / #179 established one process-wide FIFO Bridge lane: one request runs, six may queue, and excess or expired work receives a structured retryable error.
  • #176 / #177 added the direct MCP burst harness, but its contract deliberately launches one stdio server process.
  • #187 / #190 made one FocusRelay process exit when its client closes stdin.
  • #196 owns the separate Desktop-host/TCC transport decision.
  • #217 owns the docs-only correction to the current IPC contr

Read the thread · 2026-08-12 · open · 1 comment

Derive catalog cache keys from the filter instead of a hand-maintained list

User outcome

A query never receives another query's cached results. Adding a filter field cannot silently produce wrong answers, because the cache key is derived from the filter rather than maintained by hand alongside it.

Validation impact

query — changes how cached catalog results are keyed. No MCP wire change.

Current state: correct today, but only by coincidence of two hand-maintained lists

CacheKey enumerates its fields manually:

limit, cursor, fieldsKey, statusFilter

[Read the thread](https://github.com/deverman/FocusRelayMCP/issues/207) · 2026-08-02 · closed · 1 comment

### Installed plug-in is ignored when OmniFocus plug-in sync is enabled: README installs to the wrong directory

## User outcome

A user who follows the README install steps ends up running the plug-in they
just installed. Today, a user with OmniFocus plug-in sync enabled can follow
every documented step, see a healthy `bridge-health-check`, and still have
OmniFocus executing a completely different plug-in build — with no signal that
anything is wrong.

## Validation impact

`docs` for the README and troubleshooting corrections. A follow-up slice that
changes `scripts/install-plugin.sh` behavior or adds a 

[Read the thread](https://github.com/deverman/FocusRelayMCP/issues/200) · 2026-08-01 · closed · 1 comment

### Harden bridge IPC directory: retention, permissions, upgrade invalidation, fail-fast paths

## User outcome

After upgrading FocusRelay via Homebrew, I start my MCP client and run a few
queries. The IPC directory
(`~/Library/Containers/com.omnigroup.OmniFocus4/Data/Documents/FocusRelayIPC`)
contains only `requests/`, `responses/`, `locks/`, `dispatch/`, and
`bridge-version.json` — all owner-only; legacy `pid-*` folders, trace files,
and `logs/` are gone, and no artifacts from my successful calls remain. On a
Mac without OmniFocus 4 installed, a tool call returns a clear "install and
la

[Read the thread](https://github.com/deverman/FocusRelayMCP/issues/197) · 2026-08-01 · closed · 0 comments

### Exit the stdio server when its MCP client disconnects

## User outcome

When an MCP client quits or restarts, its FocusRelay server process exits promptly instead of remaining orphaned in the background.

## Validation impact

`transport-reliability`

## User-facing acceptance journey

1. A client starts FocusRelay over stdio and completes initialization.
2. The client quits or closes FocusRelay's standard input.
3. FocusRelay finishes the MCP receive loop, releases transport resources, and exits successfully within a short bounded interval.
4. Star

[Read the thread](https://github.com/deverman/FocusRelayMCP/issues/187) · 2026-07-28 · closed · 1 comment

### Tell all MCP clients to serialize mutation tool calls

## User outcome

When a user asks for OmniFocus changes in an ordinary chat instead of selecting a registered workflow prompt, the model still learns to send mutation requests sequentially and avoids a preventable burst of retryable Bridge errors.

## Validation impact

`server-wire`

## User-facing acceptance journey

1. A client loads FocusRelay's public tools.
2. The always-visible descriptions for `edit_tasks` and `edit_projects` tell the model to wait for each mutation response before start

[Read the thread](https://github.com/deverman/FocusRelayMCP/issues/185) · 2026-07-28 · closed · 0 comments

### Cover Bridge cancellation through the real MCP boundary

## User outcome

When an MCP client cancels a FocusRelay request, automated regression coverage
proves that the cancellation reaches the real FocusRelay tool boundary instead
of becoming a misleading tool error or allowing canceled queued work to reach
OmniFocus.

## Validation impact

`transport-reliability`

## User-facing acceptance journey

An assistant starts two Bridge-backed count requests and cancels the second
while it is queued. The canceled request returns cancellation to the client,

[Read the thread](https://github.com/deverman/FocusRelayMCP/issues/183) · 2026-07-28 · closed · 0 comments

### Make bridge-burst response deadline explicit and reproducible

## Context

- Follow-up to #176 / #177.
- Blocks the completion-preview live acceptance evidence for #170.

## User outcome

A developer can run the direct MCP burst harness with a response deadline that matches the client budget being tested. The resulting aggregate artifact records that deadline, so timeout evidence is interpretable and reproducible.

## Validation impact

`performance`

## User-facing acceptance journey

A developer validates the bounded Bridge coordinator with the no-write c

[Read the thread](https://github.com/deverman/FocusRelayMCP/issues/178) · 2026-07-28 · closed · 0 comments

### Add a direct MCP concurrent Bridge burst harness

Parent reliability issue: #170

## User outcome

Give maintainers a reproducible, privacy-safe way to measure how FocusRelay
behaves when an MCP client sends several Bridge-backed requests at once, so
transport changes are admitted on evidence instead of one-off interactive
failures.

## Bounded outcome

Add a developer-only direct MCP burst harness:

```bash
swift run focusrelay-dev bridge-burst \
  --profile canary \
  --scenario task-counts \
  --server-path .build/release/focusrelay

The

Read the thread · 2026-07-28 · closed · 1 comment

Design an atomic heterogeneous task edit plan for approved workflow batches

Workflow evidence: #168 and #94 Prerequisites: #170, #171, and #172

User outcome

After a user approves one bounded inbox-processing proposal, preview and apply the different renames, tag changes, moves, status changes, and completions as one explicit plan instead of dozens of homogeneous mutation calls—without weakening the established all-or-nothing preference.

Why this is discovery work

A successful real inbox-zero UAT needed 61 edit_tasks calls because the locked V1 write contract

Read the thread · 2026-07-27 · closed · 2 comments

Fetch a bounded set of task details by stable ID in one query

Workflow evidence: #168 and #94 Depends on transport guard: #170

User outcome

Let an inbox workflow expand notes or other compact fields for a selected set of ambiguous captures in one bounded read instead of issuing one get_task request per item.

Sanitized observed cost

One successful inbox-zero UAT made 28 individual task-detail calls for a 32-item inbox. The prompt correctly avoided requesting every note in the initial page, but the current read surface turns progressive expansion

Read the thread · 2026-07-27 · closed · 0 comments

The remaining reports are on the project's issue tracker.