Claude Desktop Dispatch bridge: user messages received but never routed to SDK transport (stale pendingTurns timeout)

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?

## Summary
On Claude Desktop 1.569.0 (CCD 2.1.87), the Dispatch bridge from the mobile app to desktop receives user messages successfully but never routes them to
the SDK transport for processing. Messages sit idle for ~5 minutes, then get cleared as stale. No response is ever generated.

## Environment

• OS: Windows 11 Home 10.0.26200 (x64)
• Claude Desktop: 1.569.0 (installed via winget Anthropic.Claude, Squirrel package)
• CCD version (from logs): 2.1.87
• Claude Code CLI (separate, via npm): 2.1.92 — works perfectly in terminal
• Account: Max plan

## Steps to reproduce

1. Open Claude Desktop → Code tab → Dispatch
2. Create a new Dispatch conversation
3. From the Claude iOS app → Dispatch, send any message (e.g. "salut test")
4. Wait — no response ever arrives

Also reproduces when sending from the Claude Desktop Dispatch input itself (not just mobile).

## Expected behavior
User message is written to the SDK transport, processed by Claude, and a response streams back to both desktop and mobile Dispatch thread.

## Actual behavior
Message is received by the bridge but never written to the SDK transport handle. After ~5 minutes, it's cleared as stale via [stale-reset] Removing
stranded uuid ... from processedMessageUuids.

## Log excerpt (%APPDATA%\Claude\logs\main.log)
[sessions-bridge] Created session session_01LS6bUYfacDfu8dUF1Tw971 (trigger=start)
[sessions-api] Poll received work: id=cse_01LS6bUYfacDfu8dUF1Tw971 type=session
[sessions-bridge] Connecting transport for session cse_01LS6bUYfacDfu8dUF1Tw971
[transport:bridge] gate on — using SDK adapter for session cse_01LS6bUYfacDfu8dUF1Tw971
[transport:sdk] attaching SDK bridge session cse_01LS6bUYfacDfu8dUF1Tw971 (apiBaseUrl=https://api.anthropic.com)
[transport:sdk] attached; handle ready for writes (sessionId=cse_01LS6bUYfacDfu8dUF1Tw971)
[sessions-bridge] Session work received, waiting for user message via transport
[sessions-bridge] Writing 1 Dispatch seed message(s) + idle result for session cse_01LS6bUYfacDfu8dUF1Tw971
[sessions-bridge] Received user message for session cse_01LS6bUYfacDfu8dUF1Tw971: "salut test"
(no further activity for 5 minutes)
[sessions-bridge] Stale pendingTurns detected for session cse_01LS6bUYfacDfu8dUF1Tw971 (pendingTurns=1), resetting counter and keeping transport open
[sessions-bridge] [stale-reset] Removing stranded uuid 7c96108a-f73f-40c3-bec2-a8c21713fcb3 from processedMessageUuids

The key observation: after [transport:sdk] attached; handle ready for writes, the initial seed message is written successfully (Writing 1 Dispatch seed
message(s) + idle result), so the "welcome" intro appears in the UI. But subsequent Received user message events are never followed by a
corresponding write to the SDK transport — no API call is ever made, no response is generated.

## What I tried (none fixed it)

• Cleared bridge-state.json, cleared claude-code-sessions/, cleared cache directories (Cache, Code Cache, Local Storage, IndexedDB, etc.)
• Killed all claude.exe processes and restarted — bridge reconnects cleanly but the exact same pattern repeats
• Created brand new server-side session (old cse_... was replaced by a fresh cse_...) — still no routing
• Full uninstall (winget uninstall Anthropic.Claude) + deleted %APPDATA%\Claude entirely + reinstall (winget install Anthropic.Claude) + fresh OAuth

login — same bug persists on the clean install

• Toggled keepAwakeEnabled on, verified cwd=D:\ is set for LocalSessions.getDefaultPermissionMode

## Hypothesis
The log line [transport:bridge] gate on — using SDK adapter suggests a GrowthBook feature flag gating this code path. It looks like the SDK adapter
variant has a routing bug where Received user message events from the bridge are not being forwarded to transport.write() on the attached SDK handle.
The seed message path works (single write at session creation), but the incremental user-message path does not.

## Impact
Dispatch bridge (mobile → desktop) is completely unusable on this account. Local Claude Code CLI (claude in terminal) works fine — this is specific to
the Desktop app's Dispatch bridge transport.

What Should Happen?

When I send a message from the Claude iOS app via Dispatch (Claude Code → Dispatch tab) to my paired Claude Desktop, the message should be routed to the
SDK transport, processed by Claude, and a streaming response should appear in both the mobile Dispatch thread and the Claude Desktop Dispatch panel.

The initial Dispatch "seed message" (welcome intro) is written correctly at session creation, proving the SDK transport handle works for writes.
Subsequent user messages should follow the same path and produce a response.

Formularul probabil are mai multe câmpuri structurate (nu un singur body ca am scris eu la început). Spune-mi ce câmpuri mai apar și îți dau conținut
pentru fiecare.

Error Messages/Logs

Log file: %APPDATA%\Claude\logs\main.log

  Key sequence showing the bug (timestamps from 2026-04-05):

  
  11:23:11 [info] [sessions-api] Session created: session_01LS6bUYfacDfu8dUF1Tw971
  11:23:11 [info] [sessions-bridge] Created session session_01LS6bUYfacDfu8dUF1Tw971 (trigger=start)
  11:23:12 [info] [sessions-api] Poll received work: id=cse_01LS6bUYfacDfu8dUF1Tw971 type=session
  11:23:12 [info] [sessions-bridge] Handling session work
  11:23:12 [info] [sessions-bridge] Connecting transport for session cse_01LS6bUYfacDfu8dUF1Tw971
  11:23:12 [info] [transport:bridge] gate on — using SDK adapter for session cse_01LS6bUYfacDfu8dUF1Tw971
  11:23:12 [info] [transport:sdk] attaching SDK bridge session cse_01LS6bUYfacDfu8dUF1Tw971 (apiBaseUrl=https://api.anthropic.com)
  11:23:12 [info] [transport:sdk] attached; handle ready for writes (sessionId=cse_01LS6bUYfacDfu8dUF1Tw971)
  11:23:12 [info] [sessions-bridge] Session work received, waiting for user message via transport
  11:23:12 [info] [sessions-bridge] Writing 1 Dispatch seed message(s) + idle result for session cse_01LS6bUYfacDfu8dUF1Tw971
  11:24:13 [info] [sessions-bridge] Received user message for session cse_01LS6bUYfacDfu8dUF1Tw971: "salut test"
  (no further activity — no SDK write, no API call, no response)
  11:29:13 [warn] [sessions-bridge] Stale pendingTurns detected for session cse_01LS6bUYfacDfu8dUF1Tw971 (pendingTurns=1), resetting counter and keeping
  transport open
  11:29:13 [info] [sessions-bridge] [stale-reset] Removing stranded uuid 7c96108a-f73f-40c3-bec2-a8c21713fcb3 from processedMessageUuids for session
  cse_01LS6bUYfacDfu8dUF1Tw971
  

  Related errors in %APPDATA%\Claude\logs\claude.ai-web.log (recurring):

  
  [error] [REACT_QUERY_CLIENT] QueryClient error: Error: Not found
  [error] Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'includes')
  [warn] MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 $eipc_message$_..._AutoUpdater_$_updaterState_$store$_update listeners
  added
  

  Bug signature: after `[transport:sdk] attached; handle ready for writes`, the initial seed message is written successfully, but every subsequent
  `[sessions-bridge] Received user message` event is NOT followed by any `[transport:sdk]` write — the user message is silently dropped, then marked stale
  after ~5 minutes.

  Bug persists across:
  - Full bridge-state.json reset
  - Full cache/session directory deletion
  - Full uninstall (winget uninstall Anthropic.Claude) + %APPDATA%\Claude deletion + reinstall + fresh OAuth login
  - Creating brand new server-side session (new cse_... ID each time)

Steps to Reproduce

Preconditions:

• Claude Desktop 1.569.0 installed on Windows 11 (installed via winget Anthropic.Claude, Squirrel package at %LOCALAPPDATA%\AnthropicClaude)
• Logged in to a Claude Max plan account
• Claude iOS app installed and logged in to the same account
• Keep awake enabled in Claude Desktop → Code → Dispatch settings

Steps:

1. Open Claude Desktop on Windows.
2. Click the "Code" tab at the top of the window.
3. In the left sidebar, click "Dispatch" (or click "+ New session" to create a fresh Dispatch conversation).
4. A new Dispatch thread opens showing the intro seed message: "Claude can work with your files, browse in Chrome, and use connectors..." — this confirms

the SDK transport is attached and can write.

1. On the iPhone, open the Claude iOS app.
2. Navigate to the Claude Code / Dispatch tab.
3. Open the same Dispatch conversation that was just created on desktop (it syncs across devices).
4. Type any message, e.g. "salut test", and send it.
5. Observe the desktop Dispatch panel — the user message appears on the right side of the thread with a pending/loading indicator.
6. Wait up to 5 minutes.

Expected: Claude processes the message and streams a response back into the thread on both devices.

Actual: No response ever arrives. After ~5 minutes, the desktop log emits [sessions-bridge] Stale pendingTurns detected ... resetting counter and the
message is silently dropped. The pending indicator on the message may turn into a failed state.

Also reproduces when the user message is typed directly into the Dispatch input box on Claude Desktop itself (not only from mobile) — so the bug is in the
bridge→SDK routing, not in the mobile→bridge path.

Minimal repro = just steps 1–10 above; no code or project files are needed. A completely empty Dispatch session with any text message is sufficient.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Current broken version: Claude Desktop 1.569.0 / CCD 2.1.87 (latest stable per https://api.anthropic.com/api/desktop/win32/x64/squirrel/update RELEASES endpoint).

Claude Code Version

2.1.92 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Impact

The Dispatch feature on Claude Desktop is completely unusable on this account. The intended workflow — sending tasks to Claude from the iOS app and having
them execute on the always-on desktop — does not work at all. Local claude CLI in terminal works perfectly, so this is specific to the Desktop app's
Dispatch bridge transport.

## Troubleshooting already performed (none resolved the bug)

1. Cleared %APPDATA%\Claude\bridge-state.json to {} and restarted — bridge reconnected cleanly but same bug.
2. Deleted stale session files under %APPDATA%\Claude\claude-code-sessions\<env>\<org>\*.json.
3. Cleared all Electron cache dirs: Cache, Code Cache, GPUCache, Local Storage, IndexedDB, Session Storage, blob_storage, DIPS,

SharedStorage, fcache.

1. Created a brand new server-side session (old stuck cse_01TsZqzTxBWNPGHHRWLcRAnE → fresh cse_011XqkQtZDmoWxUTJSvK9RnM → fresh

cse_01LS6bUYfacDfu8dUF1Tw971 after reinstall). Every new session exhibits the same behavior on the very first user message.

1. Full clean reinstall: winget uninstall Anthropic.Claude + rm -rf %APPDATA%\Claude + winget install Anthropic.Claude + fresh OAuth login from

zero. Bug is 100% reproducible on the clean install.

1. Verified keepAwakeEnabled: true, cwd=D:\ resolves correctly for LocalSessions.getDefaultPermissionMode, account is logged in, oauth tokens are

fresh.

1. Reproduced with messages typed directly into the Dispatch input box on Claude Desktop (not only from mobile) — so the bug is not in the mobile→bridge

path.

## Hypothesis / likely root cause
The log line [transport:bridge] gate on — using SDK adapter for session cse_... strongly suggests a GrowthBook feature flag (chicago_config) is gating
between two transport implementations, and the "SDK adapter" variant (gate=on) has a routing bug:

• At session start, [transport:sdk] attached; handle ready for writes followed by Writing 1 Dispatch seed message(s) + idle result — **this write

succeeds**, so the SDK handle is callable.

• Every subsequent [sessions-bridge] Received user message: "..." event is never followed by a corresponding [transport:sdk] write. No API call is

made, no response is produced.

• After ~5 minutes, `[sessions-bridge] Stale pendingTurns detected (pendingTurns=N) ... [stale-reset] Removing stranded uuid ... from

processedMessageUuids` — the message is silently dropped.

It looks like the incremental user-message path in the SDK adapter is not wired up to transport.write() on the attached handle, while the initial
seed-message path is. This would explain why the welcome/seed message always works but user messages never do.

## Ancillary errors in claude.ai-web.log (may or may not be related)
Recurring every time the Dispatch panel is opened:

• [REACT_QUERY_CLIENT] QueryClient error: Error: Not found
• Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'includes')
• MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 ..._AutoUpdater_$_updaterState_$store$_update listeners added

The TypeError in particular fires right around message-receive time, which may indicate the UI-side handler that should forward the message to the
transport is crashing before it can write.

## Chicago config from logs (feature flag dump)
``
[chicago] GrowthBook chicago_config: raw={"enabled":true,"pixelValidation":false,"clipboardPasteMultiline":true,"screenshotFilter":true,"mouseAnimation":t
rue,"hideBeforeAction":true,"coordinateMode":"pixels","dispatchCuGrantTtlMs":1800000} → enabled=true subGates={"pixelValidation":false,"clipboardPasteMult
iline":true,"mouseAnimation":true,"hideBeforeAction":true,"autoTargetDisplay":true,"clipboardGuard":true} coordMode=pixels dispatchTtlMs=1800000
``

## Files available on request

• Full %APPDATA%\Claude\logs\main.log (~61 KB, covers sessions across 3 different cse_... IDs and 2 Claude Desktop installs)
• Full %APPDATA%\Claude\logs\claude.ai-web.log
• bridge-state.json at various points during troubleshooting

Happy to attach any of these or provide additional diagnostic info on request.