[BUG] Cowork Dispatch entry never renders in macOS sidebar (Max) — setup unreachable, mobile pairing fails

Status Closed — duplicate
Maintainer reply None cached
Activity 1 comment · opened Aug 21, 2026 · closed Aug 25, 2026

Preflight Checklist

  • [x] I have searched existing issues — closest matches are #80058, #86031 and #84035; see "Relationship to existing reports" below for why this is a distinct variant
  • [x] This is a single bug report
  • [x] I am using the latest version

What's Wrong?

On macOS with a personal Max account, Dispatch never appears in Cowork's left panel at all — there is no entry, greyed out or otherwise, and no "Get started" affordance anywhere in the app. Setup therefore cannot be initiated from the desktop.

Pairing from the iOS app consequently fails with "Pairing failed", whose checklist leads with "Dispatch is set up in Claude Desktop" — which it cannot be. Neither side can bootstrap the other.

Environment

| | |
|---|---|
| Claude Desktop | 1.34493.0 (arm64) |
| macOS | 26.5.1 (25F80) |
| Plan | Max, personal account, single workspace (no org switcher) |
| iOS app | current; Dispatch tab present and functional |
| Account | same on both devices, confirmed in Settings → Account → Active sessions |

What Should Happen?

Opening Cowork on a never-paired desktop should present a Dispatch entry with a "Get started" / QR pairing screen, per the help article.

Diagnostic evidence

The feature is provisioned for this account — the section renders empty, it is not gated off. The desktop app's own sidebar state (Local Storage, scoped to account/org) registers a cowork.dispatch section with zero rows:

{"cowork.navHeader":5,"code.recents":4,"cowork.dispatch":0,
 "cowork.homeProjects":1,"cowork.recents":9,"cowork.scheduled":4}

Sibling counts are accurate — 9 recents and 4 scheduled tasks do exist. The section appears to be data-driven off paired devices, so with none paired it renders nothing, including the entry point required to pair one. This looks like the core defect: a circular dependency identical in shape to the one described on Windows in #84035.

The build fully implements the Dispatch host. app.asar contains the complete tool surface (start_task, start_code_task, send_message, set_agent_name, list_code_workspaces, list_projects), the dispatch_child session kind, dispatchTrustedCodeWorkspaces / dispatchCodeTasksPermissionMode settings, and onboarding copy referencing the phone's Dispatch tab. Not a missing-feature or stale-version issue.

The host never initialises. No Cowork Dispatch activity appears in any log at any point in the app's history. (String matches for "dispatch" in main.log all belong to unrelated subsystems: GrowthBook dispatchCuGrantTtlMs, [ScheduledTasks] Delaying dispatch, and systemd inside the Cowork VM.)

bridge-state.json is never created — absent from both ~/Library/Application Support/Claude/ and ~/.claude/, matching the observation in #80058.

An instrumented pairing attempt produced zero host-side activity. With the Mac held awake via caffeinate (both PreventUserIdleSystemSleep and PreventUserIdleDisplaySleep asserted) and Claude Desktop verified running and frontmost, a pairing attempt from the iOS app produced:

  • main.log — 2,636 bytes, all routine (memory sampling, session warm lifecycle, plugin fetch)
  • claude.ai-web.log0 bytes
  • swift.log0 bytes
  • mcp.log0 bytes

No inbound connection, no relay traffic, not even a rejection. The request does not reach the machine.

Ruled out

| Cause | Evidence |
|---|---|
| Stale version | 1.34493.0, updater reports current; host code present in bundle |
| Plan tier | Max, confirmed on account |
| Team/Enterprise gating | Personal account, single workspace, no org switcher |
| "Require trusted devices" | Toggled off, retested, no change (trusted-device list empty) |
| "Run new tasks in the cloud" | Toggled off, full ⌘Q restart, no change |
| Full VM sandbox mode | Not set; managed MDM value null |
| Mac asleep | Pinned awake via caffeinate during the instrumented attempt |
| App not running | Verified alive via ps throughout |
| Local preference | No Dispatch enable/disable key exists in the settings-defaults block |

Steps to Reproduce

  1. Sign into Claude Desktop on macOS with a personal Max account.
  2. Open Cowork and inspect the left panel.
  3. Observe: no Dispatch entry and no "Get started" affordance.
  4. On iOS, open the Dispatch tab and attempt to pair.
  5. Observe: "Pairing failed", checklist item 1 reading "Dispatch is set up in Claude Desktop".

Relationship to existing reports

Same family, different failure mode — worth distinguishing:

  • #80058 (macOS, Team) — Dispatch entry visible but greyed out. Here there is no entry at all.
  • #86031 (macOS, Pro) — Dispatch panel exists but renders Settings view only, no QR. Here the panel is never reachable.
  • #84035 (Windows) — entry renders then unmounts after ~250ms; names the same circular dependency. Same shape, different platform, and here it never renders even briefly.

The cowork.dispatch: 0 sidebar row count above may be the useful shared datapoint across all four, since it shows the section is provisioned and simply rendering empty rather than being withheld.

Suggested mitigation

Independent of the root cause, a fallback entry point that does not depend on paired-device state — Settings → Cowork, or the menu bar — would break the circular dependency and unblock every reporter in this family.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗