[BUG] [Cowork] Dispatch: per-tool MCP permission prompts in child task sessions are not forwarded to the mobile thread (regression)

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 child Cowork task session (spawned from a Dispatch agent thread on mobile) invokes an MCP tool that requires per-tool user approval, the "Allow / Deny" prompt is rendered only in the desktop Cowork tab and is never forwarded to the Dispatch mobile UI.

The Dispatch session reports "running" indefinitely with no turn progress and no push notification, so the user cannot unblock the work remotely. This previously worked — similar approval prompts used to surface in Dispatch on the phone — so this is a regression.

Concrete instance (2026-06-11):

• A child Cowork task ("AI bug analyzer implementation") was spawned via Dispatch.
• The child session invoked mcp__<n8n-server-id>__update_workflow to attach a credential to the "Download Image" node of an n8n workflow.
• Turn counter froze for ~25+ minutes with no Dispatch-side indication of why.
• The orchestrating Dispatch agent assumed a dead API call and proposed a fresh-session-as-fallback recovery.
• On returning home and opening the desktop Cowork tab, the user found the Allow / Deny prompt sitting there the entire time. Clicking Allow immediately resumed the session.

Impact:

• The core value proposition of Dispatch on mobile — supervising and unblocking long-running agent work away from the desk — is broken for any workflow that uses a connector with per-tool approval.
• Silent failure mode: the orchestrator cannot distinguish "blocked on user approval" from "dead API call", so it may incorrectly kill and respawn sessions, multiplying cost.
• Defeats the purpose of mobile Dispatch as a persistent agent control surface.

What Should Happen?

The per-tool MCP approval prompt issued inside a child Cowork task session should be forwarded to the parent Dispatch thread on mobile (either as an inline message with Allow / Deny buttons or as a push notification linking back to the prompt), so the user can approve or deny remotely. This matches the previous behavior the user experienced with Dispatch.

Error Messages/Logs

Steps to Reproduce

1. On a phone, open a Dispatch agent thread that has access to a desktop Cowork instance and at least one MCP server configured with per-tool approval (e.g. n8n's update_workflow).
2. From Dispatch, ask the orchestrator to spawn a child Cowork task session on the desktop (e.g. "spin up a Cowork task to attach a credential to the Download Image node in workflow X").
3. Let the child session run until it calls an MCP tool that is gated by a per-tool approval prompt (e.g. mcp__<server-id>__update_workflow).
4. Observe the desktop Cowork tab — a permission prompt is rendered there: "Claude wants to use update_workflow from n8n — Allow for this task / Allow once / Deny".
5. From the phone, observe Dispatch: the session displays as "running", turn counter does not advance, no push notification arrives, and the prompt does not appear inline or as a system message.
6. Call read_transcript on the child session from Dispatch — the approval prompt is not present in the transcript (it lives at the SDK / harness layer, not in the conversation).
7. The session remains blocked indefinitely until the user physically returns to the desktop and clicks Allow.

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 desktop app (not Claude Code CLI)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment

• Product: Claude Cowork (desktop) + Dispatch (mobile / web)
• Plan: Pro / Max
• OS: Windows
• Date observed: 2026-06-11
• Architecture: persistent Dispatch agent thread on phone delegates work to child Cowork task sessions on desktop
• Triggering tool example: update_workflow from a connected n8n MCP server (any MCP tool configured with per-call approval will reproduce)

Note
This is a Cowork / Dispatch bug, not Claude Code CLI. The form above is the Claude Code repo bug template, but per the repo's area:cowork label and existing Cowork issues (#59850, #61449, #42890, #45076, #66407, #62194), this appears to be the right channel.

Regression note
The user reports that similar permission-style prompts used to be forwarded to Dispatch on the phone:

"это работало раньше с dispatch сессиями, мне на телефоне всплывали подобные варнинги с просьбой что то разрешить" ("this worked before with Dispatch sessions — these kinds of warnings asking for permission used to pop up on my phone")

So this is a regression introduced between when that behavior was last seen and 2026-06-11.

Workaround
The user currently has to physically return to the desktop, open the Cowork tab, locate the pending approval prompt, and click Allow. Setting per-tool MCP tools to "Always allow" eliminates the prompt but is unacceptable for tools with destructive side effects (update_workflow, deletions, writes to production systems).

Suggested investigation pointers

• The prompt appears to be raised by the Cowork desktop harness / SDK layer (it is not in the conversation transcript), so the Dispatch forwarding path for harness-level UI events is the likely suspect.
• Confirm whether the breakage is specific to MCP tools mounted from connectors (vs. built-in tools), and whether per-tool vs per-session approval scope changes anything.
• Verify whether push-notification triggers for "session waiting on input" still fire for non-MCP cases (e.g. AskUserQuestion), to localize the regression to the MCP-permission code path.