Auto-update silently drops all Remote Control bridges; running sessions cannot reconnect
Bug: auto-update silently drops all Remote Control bridges; existing sessions cannot reconnect
Product: Claude Code — desktop app (Windows)
Versions involved: 2.1.266 → 2.1.270 (auto-update)
Platform: Windows 10 Pro 19045, win32:<machine>
Date observed: 2026-09-13, ~20:09 local (UTC+3)
Severity: Feature-breaking, silent, affects every session on the machine simultaneously
---
Summary
An application auto-update restarted Claude Code. The restart terminated the machine-wide
Remote Control bridge. Afterwards:
- Every Remote Control session went offline at once, across unrelated projects.
- Conversations themselves survived (resumed into the same transcript), so from the user's
point of view the app was plainly running and working — only the remote link was gone.
- No notification of any kind was shown. The user discovered it only by trying to use
Remote Control from their phone and getting nothing.
- The bridge did not re-establish itself after the restart, and there appears to be no way
to reattach an already-running session — the setting is a checkbox that reads
"future sessions will be connected", and both live sessions report kind: "interactive".
Net effect: the user must abandon and recreate every in-flight conversation to recover a
shipped feature, losing the working context of each.
---
Why this is worse than a normal restart
Remote Control is app-wide, not per-session. Two completely unrelated projects
(two unrelated repositories, separate sessions, separate
working directories) lost their remote links at the same instant, because they shared one
application process tree.
The user's own words on realising the two were unrelated:
"the tft session is different session for the tft project how is it tied to the albion session? both went down and both should be separated"
That is the correct instinct, and it is exactly why this is confusing in the field: the
failure looks like it cannot be a single cause, so users will not suspect the app.
---
Evidence
1. Every Claude process restarted at 20:09:31–20:09:38
ProcessName Id StartTime WS_MB
claude 30504 9/13/2026 8:09:31 PM 262
claude 27708 9/13/2026 8:09:31 PM 36
claude 11952 9/13/2026 8:09:32 PM 129
... (13 processes, all 8:09:3x PM)
2. It was an update, not a crash
Two live processes are running different versions on the same machine:
~/.claude/sessions/15232.json sessionId e36f56c1… kind interactive version 2.1.266
~/.claude/sessions/9952.json sessionId 4441d306… kind interactive version 2.1.270
%APPDATA%/Claude/config.json → updaterLastSeenVersion = "1.52386.6".
The crash queue is empty — sentry/queue/queue-v2.json is 2 bytes ([]), written
20:09:33 as the app came back up. So no crash was recorded; this was a clean update restart.
3. The bridge froze at the restart and is now orphaned
%APPDATA%/Claude/bridge-state.json last written 20:09:35 (never again)
It holds exactly one mapping:
<uuid-a>:<uuid-b>.enabled = True
<uuid-a>:<uuid-b>.userConsented = True
<uuid-a>:<uuid-b>.environmentId = env_…
<uuid-a>:<uuid-b>.remoteSessionId = cse_…
<uuid-a>:<uuid-b>.localSessionId = local_ditto_<uuid-a>
<uuid-a>:<uuid-b>.processedMessageUuids = [50 entries]
⚠️ That localSessionId matches neither live session (e36f56c1… or 4441d306…). It is a
stale entry for a session that no longer exists, and nothing prunes or replaces it.
4. All remote peers offline, across projects
tft overlay project Remote Control offline
<machine>-<session> Remote Control offline
Fix decode.go frozen-enum raw-arm collisions Remote Control offline
TFT mobile overlay Remote Control offline
Gmail account access Remote Control offline
pc-recon-brief.md Remote Control offline
Dispatch background conversation Remote Control idle
5. The conversation survived, which is what makes it invisible
4441d306….jsonl kept being appended to throughout and is still being written now. The session
resumed into the same transcript across two restarts (20:09 and a second at 23:18 onto
2.1.270), firing a SessionStart hook with a "previous session summary" each time — while the
remote link stayed dead.
---
Steps to reproduce
- Enable Remote Control (settings checkbox: future sessions will be connected).
- Start two Claude Code desktop sessions in different projects. Confirm both are reachable
via Remote Control from another device.
- Let the app auto-update (or restart the application).
- Observe: both conversations resume and are fully usable locally.
- Attempt to reach either from the remote device.
Expected: the bridge reconnects after restart, or the user is told it did not and offered a
way to reconnect.
Actual: all remote links are silently dead. No notification, no reconnect, no way to
reattach a running session. bridge-state.json retains a stale mapping and stops updating.
---
Suggested fixes, roughly in order of value
- Re-establish the bridge on startup for sessions that were previously bridged — this is
the actual fix.
- Tell the user. Any visible indication ("Remote Control disconnected — reconnect?") turns
a silent, baffling failure into a one-click recovery.
- Allow attaching a running session to Remote Control, not only new ones. The current
"future sessions" model means a restart costs the user every in-flight conversation.
- Prune orphaned
bridge-state.jsonentries whoselocalSessionIdno longer resolves. - Consider whether an auto-update should restart the app while sessions are live at all,
or defer until idle.
---
Impact note
The user had two long-running project sessions driven from a phone. Recovering the feature
required abandoning both conversations and starting over. The failure mode is especially
costly because it is silent, survives the thing users would check first (is the PC on? is
Claude open? — both yes), and presents as two unrelated failures at once.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗