[BUG] Dispatch responses generated but never delivered to clients (desktop Cowork & 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?
Dispatch sessions process user messages and generate responses correctly on the desktop backend, but responses are never displayed on any client — neither desktop Cowork UI nor the mobile Android app.
The user only sees a "read receipt" indicator with no response text. The backend logs confirm Turn succeeded and reportDelivery status=processed, but no response is rendered on any client. This persists across app restarts, local data deletion, and brand-new session creation.
This has been ongoing for multiple days (since ~2025-03-25 based on log timestamps).
What Should Happen?
When a user sends a message in Dispatch, the response should be displayed in the Cowork UI (desktop) and/or the mobile app. The backend generates the response correctly — it just never reaches the user's screen.
Error Messages/Logs
## Error Messages/Logs
# Backend receives message and processes successfully:
[18:43:58] [sessions-bridge] Received user message for session cse_01Q121n7ShZt7qQkMd9pTXzu: "안녕"
[18:43:58] [transport:ccr] reportState idle -> running
[18:44:09] [Result] Turn succeeded for session local_ditto_3ae9b1e6-1ea1-4564-add1-b42ced1c8ac6
[18:44:09] [transport:ccr] reportDelivery event_id=18a33232 status=processed
[18:44:09] [transport:ccr] reportState running -> idle
[18:44:09] [sessions-bridge] Query completed for session cse_01Q121n7ShZt7qQkMd9pTXzu (pendingTurns=0, isError=false)
[18:44:09] [sessions-bridge] Session cse_01Q121n7ShZt7qQkMd9pTXzu turn completed, keeping transport open for follow-ups
# Response confirmed in local JSONL:
USER: 안녕
ASSISTANT: 안녕하세요, 성요님! 오늘 뭘 도와드릴까요?
# Earlier sessions also show intermittent rate_limit errors that may have initiated the issue:
[APIError] Intermediate SDK error "rate_limit" for session local_ditto_3ae9b1e6-1ea1-4564-add1-b42ced1c8ac6 — continuing to read stream
[Result] Turn failed for session local_ditto_3ae9b1e6-1ea1-4564-add1-b42ced1c8ac6: subtype=error_during_execution, is_error=trueSteps to Reproduce
- Open Dispatch in desktop Cowork (or via mobile Claude app)
- Send any message (e.g., "안녕")
- Observe: loading indicator appears, then read receipt shows, but no response text is rendered
- Check logs —
Turn succeeded,reportDelivery status=processed, response exists in local JSONL - Check mobile app — same result, no response displayed
- Restart app, delete local session data, delete
bridge-state.jsonto force new session — same issue with brand-newremoteSessionId
Remediation attempts (all failed):
- Deleted
local-agent-mode-sessions/[accountId]/directory - Deleted
bridge-state.json(confirmed newenvironmentIdandremoteSessionIdwere generated) - Full app restart with
killall -9 Claude(multiple times) - Deleted conversation from mobile app
- Tested with brand-new clean session — Turn succeeded, response generated, still not displayed
---
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Unknown exact version — the issue appeared while using the current version after extended session usage.
Claude Code Version
2.1.85 (Claude Code)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
Key finding from log analysis:
The desktop backend works perfectly — responses are generated, logged to local JSONL, and reported as processed via transport:ccr. The Cowork VM boots correctly (4 CPU, 4GB RAM, network CONNECTED, API REACHABLE). SSE transport is healthy with normal heartbeats.
The issue appears to be in the cloud relay layer between the desktop's CCR (Cloud Control Relay) and the connected clients. Evidence:
- Desktop reports
status=processedfor response delivery - Both desktop Cowork UI AND mobile Android app fail to render responses
- Brand-new sessions with fresh
environmentIdandremoteSessionIdexhibit the same behavior - This rules out local data corruption as the cause
Related issues:
- #36157 — Dispatch causes black screen freeze
- #38049 — Dispatch stuck on "Brewing..."
- #38029 — Abnormal usage consumption on session resume
26 Comments
Similar issue?
Dispatch receives the task but crashes before the session starts.
Console logs show the sequence: task arrives → app navigates to /task/new → /cowork/agent → crash.
Root cause: ANSI escape code in model config request.
The app requests /api/organizations/.../model_configs/claude-opus-4-6[1m] — note the [1m] suffix (a terminal bold escape code). This returns 404, which causes Cannot read properties of undefined (reading 'includes') in streamInput, killing the session before it begins.
Additional issues in the same logs:
Environment: Windows 11, Claude Desktop (latest), Opus 4.6. Cowork sessions launched directly work fine — only Dispatch-spawned sessions crash.
Deleting sessions (local, remote) the the bridge file, clearing cache, restarting services, etc. doesn't solve the problem.
Same issue on macOS (Mac Mini M4). Messages marked as Read but no response displayed on either desktop or mobile. Persists across restarts, new sessions, clear background tasks, and clear memory. Started today 2026-03-28.
Dev Tools. Looks like an issue unrelated to our hosts. Many errors. CSP, scripts not found, 404:
<img width="3840" height="2280" alt="Image" src="https://github.com/user-attachments/assets/8344e802-f86f-4f6c-a6a6-f212562500d7" />
+1
Same here, mac mini with latest os and latest claude app. Messages marked as Read but no response displayed on either desktop or mobile. Persists across restarts, new sessions, clear background tasks, and clear memory. Start from Mar-27th evening.
Same issue in windows desktop + Android client
Same issue. It just thinks for a bit with the squiggly lines, then says read. Same on phone app as desktop app, and i can see the messages on both apps so that's fine, but doesn't respond. Mac Studio Tahoe 26.3.1 (a), iPhone iOS 26.4 iOS 26 Developer Beta. It was working fine earlier today, did some basis computer use tasks, but now it's not.
Same issue. It just thinks for a bit with the squiggly lines, then says read. Same on phone app as desktop app, and i can see the messages on both apps so that's fine, but doesn't respond. Turned dispatch on and off. Reconnected. Killed Claude process. restarted. Still nothing. PC Win11 and iPhone iOS 26.4
Same issue on macOS (Mac Mini M4, headless via HDMI dummy plug)
Setup: Mac Mini M4 · macOS Tahoe 26.4 · Claude Desktop latest · iPhone 14 Plus · iOS 26.4
Same issue on macOS (Mac Mini M4, headless via HDMI dummy plug)
iPhone recognizes the Mac link and asks for permission
Permission is granted
Dispatch never executes any task
No response ever appears on iPhone
Desktop Claude app was open and awake throughout
Setup: Mac Mini M4 · macOS Tahoe 26.4 · Claude Desktop latest · iPhone 14 Plus · iOS 26.4
Confirmed: messages marked as "read" but no output delivered to mobile client.
Same issue here but running on Windows and iOS app. All versions latest. It was working ok up to yesterday afternoon.
Update: Dispatch started working after updating to Version 1.1.9493 (b58a0b) and removing old active sessions (there were 10+ of them):
<img width="2549" height="1863" alt="Image" src="https://github.com/user-attachments/assets/bbca9b14-7566-4ad6-8339-06064b0212b7" />
Now:
<img width="2537" height="1804" alt="Image" src="https://github.com/user-attachments/assets/378b5d40-47e4-4da9-8460-7516bc47ec19" />
Did not work for me :(
One more thing I did was Ctrl + F5 after opening Dev Tools (I could see "Inspect" on right click, it's just a web app). Perhaps that was it?
I have this same issue. I've upgraded/rebooted/terminated active sessions. Still an issue.
working now...not sure what changed.
Experiencing the same issue across two separate accounts. Dispatch responses are generated but don't render in the main Cowork chat UI. The only way to see responses is by clicking "Show background tasks," where the full response text is visible. Notably, after toggling "Show background tasks" on once, subsequent messages do render normally in the chat even after hiding background tasks again — so it serves as a workaround. Reproducible consistently.
A user in #40281 traced a root cause for Dispatch responses not rendering: the --brief CLI flag (which gates SendUserMessage registration) is never passed in the dispatch spawn args. Without it, the agent falls back to plain text which the Dispatch UI doesn't render. The fix is one line in the SDK spawn args. My Claude is not entirely sure this is the exact cause for your issue. You should check issue #40281 for the full details.
Same issue here. macOS 26.3 (Build 25D125), MacBook Air M2 16GB, Claude Desktop v1.569.0.
Behavior:
What I've tried (all failed):
Impact: Dispatch is unusable. This is a critical feature for mobile workflows — being able to send tasks to Claude from my phone while on the go.
This is still happening as of April 3, 2026.
Adding another reproducer. Dispatch is fully broken from every client
I have paired — messages show as "Read" on the sender, no response is
ever delivered.
Environment:
All three clients show the same behavior: message sent → "Read" indicator
→ no response ever arrives. Sending from any of the three produces the
same dead end.
On the Mac side, codesign shows only com.apple.security.virtualization
is granted to Claude.app; com.apple.vm.networking is missing (see #40283).
I don't know whether that's the actual cause here or a separate bug with
the same symptom, but flagging it in case it helps correlate.
This is a regression — Dispatch worked on prior versions for me. Happy
to collect additional logs if someone from the team wants them.
It finally healed for me after archiving all dispatch jobs and updating/restarting for the nth time.
Update with additional data (M5 Pro, macOS 26.4.1 build 25E253,
Claude Desktop 1.2581.0, mobile Claude 1.2600409.1 on iOS/iPadOS 26.4.1):
Confirmed that Dispatch responses ARE being generated and delivered to
the Mac — they're just not rendering in the main chat pane. They are
visible via "See background tasks," accessible from the pulldown menu
next to the "Dispatch" title (▾ chevron). The menu also contains
"Clear background tasks," "Report content," "Clear memory," and
"Delete conversation."
Tested with trivial prompts:
"From the mac: What is 7 times 3?" → "7 times 3 is 21." ✅ (bg view)
"From the iPad: What is 7 times 4?" → "7 times 4 is 28." ✅ (bg view)
Both answers show correctly in background tasks. Main chat shows only
"Read" with no rendered response. Behavior is identical for prompts
originating from Mac, iPad, and iPhone.
Partial workaround only: unlike @tararyan99's informative and useful report, toggling
"See background tasks" on did NOT cause subsequent messages to render
normally in the main chat. On my setup the main chat stays broken
regardless of background-tasks state; the background view is the
only place responses appear.
This rules out the VM network stack as the cause (including the missing
com.apple.vm.networking entitlement flagged in #40283 — my codesign
output is still missing that entitlement, yet responses are clearly
being delivered). The bug is in the main chat rendering layer. Most
consistent with this issue (#40179) or #40281's SendUserMessage theory.
Adding another reproducer, plus a distinct log signature that I didn't see in the existing comments.
Environment
New signal in
~/Library/Logs/Claude/main.logAlongside the usual
Poll error, backing off: This operation was abortedlines, I'm also seeing explicit HTTP 503 responses from the sessions-bridge poll endpoint:The 503 variant doesn't appear in the existing comments, so noting it here in case it helps isolate whether the wedge is client-side state or an upstream bridge availability issue.
Other symptoms matching the existing reports
Dispatch ∨dropdown in the title bar also appears unresponsive to clicks, so I cannot reach "See background tasks" that way.Happy to pull more log context if it would help.
I found a fix! The Dispatch chat simply has become too long.
I was able to give commands in Dispatch, but only see result in Dispatch > Dropdown menu > See background tasks.
First backup knowledge in persistant memory
Same issue here, adding a data point.
Environment
Symptom
Dispatch messages are marked "Read" on both desktop and mobile, but Claude never delivers a response on either device. Initially showed "Desktop appears offline / Asleep"; after re-pairing the offline status cleared and messages now show "Read," but replies still never appear. Matches #54378, #45937, #40178, #49545.
Key diagnostic (rules out local/VM)
Regular non-Dispatch Cowork tasks work perfectly — I asked Claude to list my desktop files and it executed via computer use and returned the correct result. So the VM and execution layer are healthy; only the Dispatch persistent thread is dead.
Already tried (none resolved it):
This points to a stuck server-side Dispatch relay/session, not a local config problem. A backend session reset seems to be the only thing that could fix it. Happy to provide logs or version numbers.
Same issue, and it has persisted for over 2 months on my setup - Dispatch has never delivered a single response in that time.
Setup: MacBook (macOS), Claude Desktop latest version, max plan, iPhone with latest Claude iOS app.
Symptom: Messages sent from iPhone arrive on the Mac and are marked "Read" in the Dispatch panel, but no response is ever displayed on either device. The thinking indicator spins indefinitely on both.
New data point: After weeks stuck, both apps recently cleared the old Dispatch messages and the spinner stopped, suggesting a reset. I sent a fresh message from my iPhone - it was delivered and marked Read, then immediately re-entered the same stuck state (spinner on both devices, no response). So the failure recurs on brand-new messages, not just one stuck session.
Tried without success over 2 months: Dispatch toggle off/on with app refresh, multiple app updates on both devices, full quit/relaunch, logout/login on both devices, new conversations. Support ticket open 2+ weeks with no reply (Conversation ID 215474732481824).