[BUG] Desktop app: resuming a previously-bridged session doesn't re-mint a Remote Control bridge; work after the first run never reaches mobile/web

Component: Claude Code Desktop app — Remote Control / session resume
Version: 2.1.209 (native install), Windows 11
Plan: Max

Summary

When a Code session that was bridged during an earlier run is resumed in the Desktop app, the app does not establish a new Remote Control bridge. The session record retains its original (now server-side-expired) session_01… id, and the resumed process runs unbridged. As a result, only the session's first run is ever mirrored to the server. All work done in later runs is local-only, the mobile/web snapshot stays frozen at the first run, and — because the mobile Code list appears to sort by server-side last-activity — the session sinks to the bottom of the list or drops out of view.

Expected behavior

The Remote Control docs state that on resume, when the server confirms the previous session no longer exists, Claude Code creates a new Remote Control session (with a new id). A resumed Desktop session should therefore re-bridge and reflect current activity on mobile/web.

Actual behavior

No new bridge is minted on resume. The old bridgeSessionIds value is retained but points at an ended server session. The resumed process is unbridged, and its later messages never reach the server.

Evidence / reproduction

1. Create and use a session on day 1 (Remote Control at default/enabled). It bridges:

``
Remote control enabled: https://claude.ai/code/session_01<A>
``
Mobile shows the session with day-1 content.

1. Close the process. Resume the same session on a later day. The logs show only:

``
[WarmLifecycle:session] Warming up session local_<uuid> ...
`
with **no** Enabling remote control / Remote control enabled line. The record's bridgeSessionIds is unchanged (still session_01<A>), and lastActivityAt` on the record advances while no new bridge id is ever minted.

1. Open https://claude.ai/code/session_01<A> on mobile → it renders the day-1 snapshot only; all later-day messages are missing. The session does not surface in the Code list (stale last-activity).

Two independent confirmations on one machine

• Session A (long-lived, bridged day 1, resumed across ~7 days): server snapshot = day-1 run (~490 msgs); ~1,900 later messages (~80% of the session) never uploaded. Mobile labels it "last week."
• Session B (bridged day 1 = 131 msgs, resumed once ~4 days later = 80 msgs): mobile shows only the 131 day-1 messages; the 80 resume-day messages are absent. Predicted before viewing, then confirmed.
• Control: a session created, worked, and finished in a single bridged run shows correctly and completely on mobile.

Related, possibly same subsystem: two Failed to toggle remote control for local_<uuid>: Session creation failed — see debug log errors were observed on ordinary fresh sessions, ~20 min apart, with no bridgeSessionIds produced. The referenced debug log did not exist (debug\latest was a dangling symlink).

Stores: %APPDATA%\Roaming\Claude\claude-code-sessions\<orgId>\<userId>\local_<uuid>.json; logs at %APPDATA%\Roaming\Claude\logs\.

Impact

Any session a user returns to over multiple days silently stops syncing to mobile/web after its first run. The sessions most affected are exactly the long-lived, frequently-resumed ones a user is most likely to want on their phone. There is no error or UI indication — the mobile view simply shows stale content and sorts the session out of sight, which reads as "the session is missing" rather than "the session stopped bridging."

Suggested fix

On resume, if the stored bridge id no longer resolves server-side (session ended/expired), mint a new Remote Control session per the documented behavior and update bridgeSessionIds. Surface Session creation failed to the UI rather than only to a debug log that may not exist.