[BUG] Dispatch responses generated but never delivered to clients (desktop Cowork & mobile)

[windruuner-design]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• 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=true

Steps to Reproduce

1. Open Dispatch in desktop Cowork (or via mobile Claude app)
2. Send any message (e.g., "안녕")
3. Observe: loading indicator appears, then read receipt shows, but no response text is rendered
4. Check logs — Turn succeeded, reportDelivery status=processed, response exists in local JSONL
5. Check mobile app — same result, no response displayed
6. Restart app, delete local session data, delete bridge-state.json to force new session — same issue with brand-new remoteSessionId

Remediation attempts (all failed):

• Deleted local-agent-mode-sessions/[accountId]/ directory
• Deleted bridge-state.json (confirmed new environmentId and remoteSessionId were 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=processed for response delivery
• Both desktop Cowork UI AND mobile Android app fail to render responses
• Brand-new sessions with fresh environmentId and remoteSessionId exhibit the same behavior
• This rules out local data corruption as the cause

Related issues:

• [Cowork] Dispatch causes black screen freeze, requires full data wipe to recover #36157 — Dispatch causes black screen freeze
• Remote Control: Dispatch stuck on "Brewing..." - no response from spawn session (Windows 11) #38049 — Dispatch stuck on "Brewing..."
• [BUG] Abnormal Usage Consumption on Claude Code Session Resume — Possible Bug #38029 — Abnormal usage consumption on session resume

[phuryn]

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:

• CSP blocks a-api.anthropic.com/v1/m — domain not in the connect-src directive
• /api/bootstrap and /api/account_profile intermittently return 403
• accounts.google.com/gsi/client times out (ERR_CONNECTION_TIMED_OUT)
• EventEmitter memory leak warning on IPC listeners (11 eipc_message listeners)

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.

[Modo3337]

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.

[phuryn]

Dev Tools. Looks like an issue unrelated to our hosts. Many errors. CSP, scripts not found, 404:

[nexusstudiopr-source]

+1