[BUG] Dispatch never shows QR / "Get Started" pairing screen on macOS — pairing state appears server-side and unresettable (Pro, never worked)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On macOS, the Dispatch panel in Claude Desktop never displays the QR code or the initial "Get Started" pairing screen. It only ever renders the Settings view, so there is no way to initiate pairing with the mobile app at all.

This has never worked on my account — the QR screen has not appeared a single time since I first opened Dispatch.

All documented client-side recovery paths fail to reset the state:

• "Delete conversation" from the three-dot menu does not reset pairing
• Deleting ~/.claude/bridge-state.json does not reset pairing
• A full reinstall of Claude Desktop does not reset pairing

Because no local action returns the panel to the pairing screen, the pairing/relay state appears to be held server-side and is not reachable from the client.

What Should Happen?

Opening Dispatch on a desktop that has never been paired should present the "Get Started" screen with a scannable QR code, allowing the mobile app to pair.

Failing that, clearing local state (deleting bridge-state.json, deleting the conversation, or reinstalling the app) should return Dispatch to the QR pairing screen.

Error Messages/Logs

No error message is displayed. The Dispatch panel silently renders only the Settings view — no QR code, no "Get Started" screen, no failure notice.

Steps to Reproduce

1. Open Claude Desktop on macOS → Cowork → Dispatch
2. Observe: the panel shows only Settings. No QR code and no "Get Started" pairing screen is ever rendered.
3. No pairing can be initiated from mobile, because there is no code to scan.

Troubleshooting already attempted — none of it restored the QR pairing screen:

• Logged out on both desktop and mobile, then logged back in desktop-first, mobile-second
• Fully quit Claude Desktop from the menu bar (not just closing the window) and relaunched
• Toggled Dispatch off → hard refresh (Cmd+R) → on
• Deleted ~/.claude/bridge-state.json and relaunched the app
• Used "Delete conversation" from the three-dot menu
• Fully uninstalled and reinstalled Claude Desktop (not just updated)
• Disabled VPN and verified the firewall was not blocking the app

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

N/A — this is a Claude Desktop / Cowork issue, not the Claude Code CLI

Platform

Other

Operating System

macOS

Terminal/Shell

Other

Additional Information

Environment

• Plan: Pro (Dispatch is listed as available on Pro per https://code.claude.com/docs/en/feature-availability)
• Claude Desktop version: 1.28929.0
• macOS version: 26.6.1
• Mobile: Claude iOS app, latest version
• Same Anthropic account on desktop and mobile: yes

Related reports

This appears to share a root cause with an existing cluster:

• #67682 — Dispatch permanently stuck, never resets to QR pairing state (Windows 11, Pro). Same symptom set: Settings-only panel, "Delete conversation" ineffective, bridge-state.json deletion ineffective.
• #75416 — same, labelled duplicate by maintainers, with the same conclusion that pairing/relay state is held server-side.

Also related: #44225, #45937, #51389, #58097, #70471.

One difference worth noting

The reporters in #67682 and #75416 had a working pairing that broke. On my account pairing was never established at all — the QR screen has never rendered once. If the server-side relay record is created lazily on first pairing, a never-paired account failing this way may point to a provisioning bug rather than a stale-state bug. The user-visible outcome is the same: the client has no path back to the pairing screen.

Request

Could the Dispatch pairing state for my account be force-reset or re-provisioned server-side? Similar requests appear in #58097 and #67303. I am happy to provide the account email privately through whichever channel you prefer.

I also attempted the in-app support route first — the Claude Desktop "Get help" flow did not produce a usable conversation, which is why I am filing here.