[BUG] [Cowork] [Dispatch] Permission prompts pinned to original device — mobile-originated Dispatch session continued on desktop still routes prompts back to mobile

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?

When a Dispatch session is created on one device and then continued from another device, MCP per-tool permission prompts continue to be routed to the device the session was originally created on, rather than to the device that currently has the session open. The active device shows no prompt and no UI indication that the session is blocked — tool calls just appear to fail / hang.

Concrete instance (2026-06-11 → 2026-06-12):

• Dispatch session was created on 2026-06-11 from the mobile Claude app.
• On 2026-06-12 the same Dispatch session was continued from the desktop Claude app.
• During desktop work, the session invoked MCP tools that needed per-tool approval (Claude in Chrome MCP — navigating to a new domain).
• The desktop window showed no prompt and no blocked-state indicator. From the desktop side it looked like the tool calls were silently erroring with Tool permission stream closed before response received after a timeout. Multiple retries all failed the same way.
• The user only discovered the issue by opening the mobile Claude app, where the permission prompts had been waiting. Approving them on mobile immediately unblocked the desktop session.

Impact:

• Cross-device continuation of Dispatch sessions is broken for any session that hits a per-tool permission gate — a core mobile-to-desktop workflow.
• The blocking failure mode is invisible on the active device: no banner, no notification, no UI state. The MCP tool surfaces as a stream-closed error, which looks like a tool/MCP-server fault rather than a pending user input.
• Combined with #67873 (the inverse direction: prompts in a desktop child session spawned from mobile Dispatch are not forwarded to mobile), there is currently no reliable way to route per-tool permission prompts to wherever the user actually is.

What Should Happen?

Per-tool MCP permission prompts should be delivered to the device that currently has the Dispatch session in the foreground / is the active client for that session. If the user switches devices mid-session, prompts should follow them. Prompts must not be pinned to the device where the session was originally created.

At minimum, the active device should show some UI indication that the session is blocked waiting on a prompt on another device, instead of failing silently.

Error Messages/Logs

Steps to Reproduce

1. From the mobile Claude app, create a new Dispatch session and run it for a turn or two (any tool calls that don't need per-tool approval are fine).
2. Close or background the mobile app.
3. On a desktop, open the same Dispatch session in the desktop Claude app and continue the conversation.
4. Have the session invoke an MCP tool that requires per-tool approval — e.g. Claude in Chrome navigate to a domain not yet permitted, or any connector tool configured for per-call approval.
5. Observe the desktop window: no permission prompt appears, no notification, no "waiting on input" state. The tool call eventually surfaces an error (in this case Tool permission stream closed before response received).
6. Open the mobile Claude app: the permission prompt is sitting there.
7. Approve on mobile — desktop session immediately resumes the tool call.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A — Cowork / Dispatch (not Claude Code CLI)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment

• Product: Claude Cowork / Dispatch
• Plan: Pro / Max
• Desktop OS: Windows
• Mobile: Claude mobile app
• Session created: 2026-06-11 (mobile)
• Session continued / observed: 2026-06-12 (desktop)
• Triggering tool: Claude in Chrome MCP navigate to a new domain (any per-tool-approval MCP call reproduces)

Related

• #67873 — the inverse direction. Child Cowork desktop task sessions spawned from a mobile Dispatch thread don't forward their permission prompts back to mobile.

Together the two reports suggest a single root cause: per-tool permission prompts appear to be tied to the SDK / harness layer of the client that first opened the session, rather than tracked per-active-client. Whichever direction the session crosses devices, prompts end up on the wrong one.

Note
This is a Cowork / Dispatch bug, not Claude Code CLI — same caveat as #67873. Filing here per the repo's area:cowork label and existing Cowork issues.

Reporter symptom from the desktop client side
The failing tool calls returned Tool permission stream closed before response received repeatedly. That string is a useful keyword for engineers searching logs — it's what the harness emits when a prompt has been issued but no client claims it within the timeout. A clearer error like "Prompt waiting on another device (mobile)" would already be a meaningful UX win even without fixing the routing.

Suggested investigation pointers

• Where is the routing decision made for permission prompts in a multi-client Dispatch session?
• Is there a per-session "active client" concept, and is it updated on client foreground / reconnect?
• Confirm whether AskUserQuestion and other interactive harness events have the same routing behavior, or whether this is MCP-permission-specific.