Code tab: "remote control disconnected" when resuming any session whose CLI owner is gone (e.g. after PC restart)

Bug Report: Claude Desktop "Code" tab — remote control disconnected when resuming any session whose original CLI owner process is gone

Title (for GitHub)

Code tab: cannot resume sessions after the original CLI owner exits — "remote control disconnected" instead of spawning a new CLI to take over

Summary

Claude Desktop's "Code" tab silently breaks for any saved session whose original owner CLI process is no longer running (after PC restart, terminal closed, or previous Desktop instance terminated). Clicking such a session in the sidebar and sending any message produces リモートコントロールが切断されました / The bridged Claude Code process stopped responding mid-turn. Check your terminal for errors (you may need to run /login).

This is a regression: previously you could shut down the PC, reopen Desktop, click an existing session, and continue. Now every saved session that doesn't have a live owner is dead-on-arrival from Desktop's UI.

New sessions (+ New session) created from Desktop work fine — only resume of orphaned existing sessions is broken.

Environment

• OS: Windows 11 Enterprise 10.0.26200
• Claude Desktop version: 1.7196.1 (Win32 Squirrel, %LOCALAPPDATA%\AnthropicClaude\app-1.7196.1\). Originally observed on 1.8089.1 (Microsoft Store / MSIX) — confirmed the same bridge symptom occurs in both versions.
• Bundled Claude Code SDK ("CCD"): 2.1.142 (downloaded by Desktop into ~\AppData\Roaming\Claude\claude-code\2.1.142\claude.exe)
• User-side CLI (separate npm-installed): 2.1.145 — running and healthy throughout (not affected)
• Distribution / install path: switched from MS Store MSIX to Win32 installer (https://downloads.claude.ai/releases/win32/x64/1.7196.1/Claude-abcd6556f79f4cca317ff02bfe0bedbeeb6e56a9.exe, SHA256 3d39a236267b17ea17e976015ca5f4a66a986a1324bab1d59529d36055b46afc) — bug persists.

Steps to Reproduce

1. Open PowerShell, run claude to start a terminal CLI session in some project directory. Use it (send a message, save automatic transcript).
2. Close that terminal (or restart the PC — anything that kills the owner process).
3. Open Claude Desktop.
4. In the Code tab sidebar, click on the saved session from step 1 (or any pre-existing session whose owner is no longer running).
5. Send any message (e.g., hello).

Expected behavior

Desktop should detect that the owner process is gone and either:

• Spawn a fresh CCD child process (claude.exe) and have it "adopt" / re-attach to the saved session by loading the transcript and continuing, or
• Show a clear "this session's process is no longer running; click here to take over with a new process" UI, or
• At minimum show a clear error message that distinguishes "owner gone" from "bridge IPC broken".

Either way, the user should be able to keep working in the saved session as they could in previous Desktop versions.

Actual behavior

• Desktop sets focus to the session ID:

``
[info] [CCD] LocalSessions.setFocusedSession: sessionId=session_01F2YS3Sy1azY1qmu93YZ2E6
``

• User types hello and presses send.
• No LocalSessions.sendMessage, no Starting local session, no Using Claude Code binary at entries follow in main.log — i.e., Desktop never reaches the spawn-CCD path. It is stuck trying to bridge to a dead process.
• After timeout, Desktop UI shows:

```
リモートコントロールが切断されました
ターミナルのClaude Codeセッションが応答しなくなりました。ターミナルでエラーを確認してから、メッセージを再送信してください。

The bridged Claude Code process stopped responding mid-turn.
Check your terminal for errors (you may need to run /login), then resend your message.
```

• The hint you may need to run /login is misleading — the user is fully authenticated, the auth cache (~/.claude/.credentials.json) is fresh, and concurrent terminal CLI sessions on the same account work perfectly.

Logs

From %APPDATA%\Claude\logs\main.log (Win32 install, 1.7196.1):

2026-05-20 14:55:58 [info] [CCD] Initialized with version 2.1.142
2026-05-20 14:56:04 [info] [buddy] starting bridge
2026-05-20 14:56:04 [info] [buddy] bridge started
2026-05-20 14:56:45 [info] [sessions-bridge] account-change reevaluate: <none> → <ORG>:<ACCT>
2026-05-20 14:56:53 [warn] [CCD] Binary preflight: .verified marker missing but binary exists at C:\Users\<USER>\AppData\Roaming\Claude\claude-code\2.1.142\claude.exe. Proceeding with spawn.
2026-05-20 14:56:53 [error] Failed to get commands from temporary query { error: Error: spawn EBUSY, ... }
2026-05-20 14:56:53 [error] Failed to get agents from temporary query  { error: Error: spawn EBUSY, ... }
2026-05-20 14:56:59 [info] [CCD] Installed at C:\Users\<USER>\AppData\Roaming\Claude\claude-code\2.1.142\claude.exe
2026-05-20 14:57:07 [info] [CCD] LocalSessions.setFocusedSession: sessionId=session_01F2YS3Sy1azY1qmu93YZ2E6
2026-05-20 14:57:08 [info] LocalSessions.checkGhAvailable: cwd=C:\Users\<USER>\ws\cdnw-demo-portal\.claude\worktrees\stupefied-bassi-45d9e7

After this point, while the user typed hello and sent it, no further session-related entries are written for that session. There is no Starting local session, no Using Claude Code binary at, no stderr capture — only continued polling for an unrelated Coder/dev-container integration. The Desktop UI eventually displays the disconnect notification.

The same setFocusedSession → silence pattern reproduces every time on this orphaned session.

Confirmed scope / variations

• Reproducible across versions: same symptom in MSIX 1.8089.1 (Microsoft Store) and Win32 Squirrel 1.7196.1.
• Not auth-related: .credentials.json is fresh, sign-out / sign-in does not help, and parallel terminal CLI sessions on the same user account work perfectly throughout.
• Not network-related: API works fine for the concurrent terminal CLI sessions; downloads from the Anthropic CDN succeed during this same window.
• Not MCP-config-related for this issue: even after disconnecting all claude.ai Connectors (Google Calendar / Google Drive), the symptom persists exactly as before.
• + New session works fine on the same Desktop install, same project. Only resume of orphaned session is broken.

Workaround currently in use

1. + New session for any work — Desktop will spawn its own fresh claude.exe and behave correctly.
2. For past content, fall back to: claude --resume <session-id> in a fresh terminal, or browse the session in the claude.ai web UI and manually copy what is needed.
3. (Unrelated but related fix) Disabled Desktop auto-update via HKLM:\SOFTWARE\Policies\Claude\disableAutoUpdates=1 to avoid the separate Invalid MCP configuration: "computer-use" is a reserved MCP name crash that the latest 1.8089.1 produces with bundled CCD 2.1.142.

Related issues (possibly distinct, possibly siblings)

• #39270 — "Claude Code process exited with code 1" (macOS/Win, general)
• #51886 — MSIX child process exits with code 1 immediately on spawn
• #52766 — Desktop Windows: exited with code 1 every session (closed as duplicate of #39270)
• #53281 — Code tab local sessions crash immediately, ccd_session/ccd_directory IPC failure
• #48362 — Windows Store/MSIX session persistence broken (EXDEV)

The bug described in this report is distinct from the above (those all fail at spawn / MCP injection; this one never reaches spawn — it is a fallback failure when the owner is already gone). But the bridge / CCD subsystem rewrite suggested by those issues may be the same code path.

Suggested fix direction (best guess from a user, not Anthropic-affiliated)

When LocalSessions.setFocusedSession is called with a session whose owner PID is no longer alive (or whose remote-control bridge handshake fails on first message), Desktop should fall back to spawning a fresh CCD child and resuming the session from the persisted transcript (already on disk in ~\AppData\Roaming\Claude\claude-code-sessions\<org>\<acct>\<session>.jsonl), rather than waiting on a bridge that will never connect.

---

(This file generated 2026-05-20 by debug session of a user hit by the bug. Logs anonymized: <USER>, <ORG>, <ACCT>. Full unsanitized logs available on request.)