Remote Control never registers for mobile after a Desktop window/pane is reused for a new conversation (stale internal session handoff)

Title: Remote Control never registers for mobile after a Desktop window/pane is reused for a new conversation (stale internal session handoff)

Preflight Checklist

• [x] Searched existing issues; closest matches are #31487 / #30922 (mobile session list staleness, both auto-closed without a confirmed fix) and #75229 (same internal clearStaleResumeHandle mechanism causing conversation history loss on macOS) — this report describes a different symptom (Remote Control never syncing to mobile) tied to the same underlying window-reuse mechanism, which I could not find previously reported.
• [x] Single bug report
• [x] Using latest available Desktop app build I have installed

What's Wrong?

When a Desktop app window/pane is reused for a new conversation (the previous conversation in that pane was cleared, and the pane was then resumed with a different underlying CLI session), enabling Remote Control on the new conversation in that reused pane produces a normal-looking success sequence in main.log (bridge_state: ready → Remote control enabled: <url> → bridge_state: connected, no errors) — but the session never appears in the mobile app's Remote Control / Code tab. A separate, unrelated conversation running in a pane that was not reused (started fresh, no clear/resume in its history) enabled Remote Control around the same time and synced to mobile correctly.

Steps to Reproduce (reconstructed from main.log)

1. Open a Desktop window/pane; start a conversation (local_cfc1ef36... was mapped to CLI session 56302337-...).
2. Clear that session (LocalSessions.clearSession). Log shows:

``
[CCD] clearStaleResumeHandle session=local_cfc1ef36... reason=clearSession
dropping cliSessionId=56302337-... unarchivedCliSessionId=undefined
``

1. In the same pane, send a new message. The app cold-starts a new session in that pane and maps it to a different CLI session:

``
Mapping internal session local_cfc1ef36... to CLI session 900f4dd0-...
``

1. Later, enable Remote Control on this pane (the new conversation, 900f4dd0-...):

``
Enabling remote control for session local_cfc1ef36...
[remote-control] bridge_state: ready
Remote control enabled: https://claude.ai/code/session_01WwyQ3x3NhL2ahdKjq1oD1z
[remote-control] bridge_state: connected
``
No errors logged. Everything here looks identical to a normal successful enable.

1. Check the mobile app's Remote Control / Code tab: this session does not appear.
2. For comparison, a separate pane that was never reused (local_ef32eac9..., mapped once to CLI session 041b4b2e-..., no clear/resume churn) enabled Remote Control around the same time and did appear correctly on mobile.

Expected Behavior

Enabling Remote Control on a conversation should register it for mobile regardless of whether the hosting Desktop pane was previously used for a different, now-cleared conversation.

Hypothesis

The pane-reuse lifecycle (clearSession → cold-start on next message → new cliSessionId mapped to the same internal local_... pane id) appears to leave some downstream identity/registration state inconsistent. main.log shows the app itself flags this handoff as dropping a "stale resume handle" during the clear step. In #75229, this exact mechanism (same log line, clearStaleResumeHandle) is already confirmed to cause a distinct, more severe bug (total conversation history loss) on macOS. This report suggests the same fragile handoff may also affect whatever registers a session as reachable from the mobile Remote Control client, on Windows, without necessarily throwing any visible error — enable "succeeds" from the Desktop's point of view, but the registration silently doesn't reach mobile.

Environment

• Claude Desktop app version: 1.20186.1 (isPackaged: true)
• Platform: Windows (win32, x64)
• Bundled CLI version: 2.1.165

Related Issues

• #31487, #30922 — mobile session list staleness / active session not visible (both auto-closed without a confirmed fix)
• #75229 — clearStaleResumeHandle mechanism confirmed to cause conversation history loss (macOS); same internal mechanism, different symptom
• #77915 — separate bug hit in the same troubleshooting session (Remote Control disable always throws due to a missing null guard); unrelated root cause, mentioned here only because it occurred in the same reused pane while investigating this issue