Desktop: New session opens an existing bridge session's thread when the bundled CLI hot-swaps (required_version change) at the click

Summary

Clicking New session in the Desktop app opened an existing Remote Control (bridge) session's thread instead of a fresh session. My next message landed in that old thread. A new bridge session was still created server-side about 90 seconds later, so the two conversations ended up interleaved across two sessions.

The Desktop main.log shows the app hot-swapped its bundled CLI (fallback_version 2.1.255 -> required_version 2.1.258) at the exact moment of the click and reset its local session focus, then re-focused an existing session.

Environment

• Desktop app 1.46388.1 (Windows 11 Pro 10.0.26220, Electron build under AppData\Local\AnthropicClaude\app-1.44121.4)
• Bundled CLI swapped 2.1.255 -> 2.1.258 during the event; native CLI on the machine 2.1.259
• A claude remote-control hub (server mode, --permission-mode auto) is running in the same directory; all sessions involved are bridge sessions in that environment
• The hub banner read Capacity: 33/32 at the time (34 non-archived sessions in the environment, 10 with live workers). Archiving idle sessions later brought it to 7/32; I could not reproduce the merge afterward, so I cannot say whether capacity is related

Timeline (Pacific, 2026-09-03)

• 21:50:12 click New session in Desktop
• 21:50:29 to 21:50:45 Desktop focuses two existing bridge sessions instead of a new one
• 21:51:41 a new bridge worker spawns for a new session (cse_0119Firtt...)
• 21:51:59 the old session (cse_01T73ztt..., "GitHub issue #76530") finishes its previous turn
• 21:52:02 my "new session" prompt is delivered to the NEW session
• 21:52:04 my follow-up typed in the Desktop thread is delivered to the OLD session

Desktop main.log excerpt

2026-09-03 21:50:12 [info] [CCD] LocalSessions.setFocusedSession: sessionId=null
2026-09-03 21:50:12 [info] [CCD] LocalSessions.setFocusedSession: sessionId=null
2026-09-03 21:50:12 [info] [CCD] Resolved CLI identity changed (fallback_version:2.1.255:94c7203f... -> required_version:2.1.258:94c7203f...) - clearing commands cache
2026-09-03 21:50:13 [info] [PluginsFetcher] fetchPluginEnabledState: 5 overrides
2026-09-03 21:50:13 [info] [CCD] /stats (worker) scanned 1090/1090 transcript files since 2026-03-05
2026-09-03 21:50:19 [info] [LocalPluginsReader] Found 6 local plugins
2026-09-03 21:50:29 [info] [CCD] LocalSessions.setFocusedSession: sessionId=null
2026-09-03 21:50:29 [info] [CCD] LocalSessions.setFocusedSession: sessionId=session_01T73zttMakGLcrZXojRzf5a
2026-09-03 21:50:44 [info] [CCD] LocalSessions.setFocusedSession: sessionId=null
2026-09-03 21:50:44 [info] [CCD] LocalSessions.setFocusedSession: sessionId=session_01MaynUHpb4NPUFxPdsL3hLr
2026-09-03 21:50:45 [info] [CCD] LocalSessions.setFocusedSession: sessionId=null
2026-09-03 21:50:45 [info] [CCD] LocalSessions.setFocusedSession: sessionId=session_01T73zttMakGLcrZXojRzf5a

Expected

New session creates and focuses a fresh session, regardless of a CLI version swap happening at the same time.

Actual

Desktop focused an existing bridge session and routed my typed message there, while a separate new session was created out of view.

Notes

• The required_version swap is not documented anywhere I could find, and there is no setting to pin the CLI the Desktop app drives (related: #84823).
• Adjacent but different: #27751 (new session while another is active corrupts history), #50388 (New Session button unresponsive on Windows).
• Happy to provide the full main.log window or the session ids privately.