Desktop: local session's remote-control bridge is never re-registered after app restart — session permanently invisible/stale on mobile and web

Summary

A Claude Desktop local session's remote-control registration happens exactly once, at session creation ([rcAutoEnable] → Enabling remote control). If the server-side session record later becomes detached from its worker (in our case: app quit while the session was mid-turn, and the server record additionally ended up archived), nothing on the client ever re-registers it:

• warm resume goes through [CCD] Warming session … — no rcAutoEnable;
• a full app restart also restores the session via the warm path — no rcAutoEnable;
• opening the session from the mobile app produces zero activity in the desktop log (desktop is not subscribed);
• sending messages into the session from the desktop works locally but nothing is synced up to the server copy.

Result: the session works fine on the desktop, but on claude.ai/mobile it is frozen at its last synced state (3+ days old for us). The claude.ai web view of that session shows:

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

Messages sent from mobile reach the server copy (they render in the web transcript) but are never delivered to the desktop, and "Try again" cannot help because the worker it waits for is gone forever.

There appears to be no recovery path at all for such a session — no UI action ("Close session" doesn't exist in the sidebar context menu; Fork does not register remote control for the forked copy either, verified in logs), no setting, no restart sequence. The only workaround is to abandon the session and start a new one.

Environment

• macOS (Darwin 25.5.0), Claude Desktop with CCD local sessions
• bundled claude-code binary: 2.1.221 at session creation, 2.1.222 currently
• remote access preference enabled ([rcAutoEnable] verdict: enable=true source=explicit_pref)

Log-backed timeline (times local, UTC+9)

Session: local_b9656108-… → CLI session 87a2c1a8-…, server id session_018qB6t5r1MVMhgwyAkes59o.

Aug 7 17:43 — creation, registration works:

17:43:24 LocalSessions.start:
17:43:24 [rcAutoEnable] verdict: enable=true source=explicit_pref
17:43:24 Enabling remote control for session local_b9656108-…
17:43:26 [remote-control] bridge_state: ready
17:43:26 Remote control enabled: https://claude.ai/code/session_018qB6t5r1MVMhgwyAkes59o
17:43:27 [remote-control] bridge_state: connected

Aug 7 20:11 — app quits while this session is mid-turn:

20:11:00 Stopping session local_b9656108-…

(the corresponding server record stays wedged: "stopped responding mid-turn")

Aug 8 and Aug 10 — app restarts; the session is only ever warmed, never re-registered:

13:32:36 [CCD] Warming session local_b9656108-…
13:32:36 [CCD] Session local_b9656108-… warmed successfully in 36ms

No rcAutoEnable / Enabling remote control line for this session ever again. Meanwhile sessions created after the restarts register fine (e.g. Enabling remote control at 09:14, 11:23, 12:52 on Aug 10) and are visible/live on mobile.

Aug 10 13:50 — message sent from the mobile app into this session: renders in the server-side transcript, desktop log shows zero activity for the session.

Aug 10 13:58 — message sent from the desktop into this session: processed locally (Stop hook completes 13:59:22), no upward sync; server copy still shows Aug 7 as the last content.

Expected behavior

Some reconciliation path should exist, e.g.:

• on app startup, re-register remote control for live local sessions whose server worker is gone (instead of only warming them);
• or on-demand: when the server receives traffic for a session whose worker is dead, ask the device (the remote-tools-device channel is connected and authenticated) to re-attach;
• at minimum: a manual "reconnect remote access" action per session in the desktop UI.

Additional notes

• While the server record was archived, the session silently disappeared from the mobile session list with no indication on the desktop that anything was wrong — the desktop UI never surfaces per-session remote-control state.
• The sidebar context menu offers no way to fully close/stop a session (only Archive/Delete), so a user cannot even force a cold LocalSessions.start manually.