claude-code - 💡(How to fix) Fix [BUG] Code session shared via Dispatch becomes unrecoverable in UI after app restart — sessions-bridge auto-disposes, CLI resume works

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?

After restarting the desktop app, an existing Code session that had been shared with a paired mobile device via Dispatch becomes permanently unresponsive in the UI.

The sidebar shows the session and its full transcript loads correctly, but the input field shows "Your terminal's Claude Code session stopped responding. Check your terminal for errors, then resend your message." — even though the session was created entirely in the desktop GUI, never in a terminal. No way to recover from the UI itself; the session is effectively dead.

Critically: the same session resumes successfully via the bundled CLI (claude --resume <cliSessionId>), confirming the local .jsonl transcript is healthy and the failure is in the desktop's serverside-bridge layer for shared (Dispatch) sessions.

Other Code sessions on the same account that were never paired with mobile open and work normally on the same app version.

What Should Happen?

On app restart, a Dispatch-shared Code session should either:

• Reconnect cleanly to its serverside bridge and remain interactive, OR
• Detect that the bridge gate is unavailable and gracefully fall back to local-only operation (the same mode CLI uses, which works), OR
• Surface an explicit recovery action in the UI ("Continue locally without Dispatch") instead of showing a misleading "terminal session" error.

The error message itself is also misleading — there is no terminal involved; the session lives entirely in the GUI.

Error Messages/Logs

UI message: "Your terminal's Claude Code session stopped responding. Check your terminal for errors, then resend your message."

main.log shows the bridge reconnects successfully on app start, then auto-disposes ~90 seconds later:

[sessions-bridge] Reconnecting persisted session cse_018Qb2nbfaNY6AkjRmtmQqBa
[sessions-api] Reconnecting session cse_018Qb2nbfaNY6AkjRmtmQqBa to environment env_013zjxMP92NfuyhDPVQzLPfQ
[sessions-bridge] Session cse_018Qb2nbfaNY6AkjRmtmQqBa reconnected successfully
...
[sessions-bridge] Disposing (pref disabled or gate off)
[sessions-bridge] Disposing...

After dispose, the renderer enters a focus loop on the affected session — same pattern as #49676:

LocalAgentModeSessions.getSupportedCommands: sessionId=undefined, cwd=undefined
[CCD] LocalSessions.setFocusedSession: sessionId=null
[CCD] LocalSessions.setFocusedSession: sessionId=session_01EczMYGhVB1aS6LyrwhEWwW
[CCD] LocalSessions.setFocusedSession: sessionId=null
(repeats indefinitely on every focus attempt)

Notably, no [Cowork]/VM startup lines appear during these focus attempts — the renderer fails before reaching VM spawn, so VM-level workarounds (service restart, etc.) have no effect.

Bridge env_id: env_013zjxMP92NfuyhDPVQzLPfQ
Bridge session id: cse_018Qb2nbfaNY6AkjRmtmQqBa
Local session id: local_66be3f60-1910-4073-8a76-4b3326b4ac6c
CLI session id: ec7f2b88-01e4-4b49-83b9-4cf8e76639ec

Steps to Reproduce

1. On Windows MSIX build 1.6608.0.0, create a Code session in the desktop GUI, work in it for an extended period (in my case: 1h 42m, ~415k tokens, 75 turns).
2. Pair a mobile device via Dispatch so the session syncs across devices.
3. Restart the desktop app (auto-update or manual quit; in my case the app updated and restarted itself).
4. Reopen the affected session from the sidebar.

Result: Transcript loads, but input is locked with "session stopped responding" error. No UI-side recovery is possible.

Verification that the data is healthy: 5. Open a terminal in the same project directory. 6. Run claude --resume <cliSessionId> — session resumes successfully with full history.

Other (non-Dispatch) Code sessions on the same machine and account open and work normally.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.128

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Additional context on regression status:

• I enabled Dispatch (mobile pairing) on this session for the first time today, so I don't have a baseline of "how it worked before Dispatch was added".
• However, the desktop app updated twice today. After the first update, the Dispatch-shared session worked normally. The bug appeared only after the second update / restart.
• This suggests the issue is either: (a) introduced by the most recent update specifically, or (b) a latent bug in the bridge-reconnect path that triggers when a Dispatch-shared session is reopened after app restart (regardless of update).
• I cannot reliably distinguish (a) from (b) from a single user's perspective.