Auto-update silently drops all Remote Control bridges; running sessions cannot reconnect

Status Open
Reported on v2.1.266
Maintainer reply None cached
Activity 2 comments · opened Sep 13, 2026

Bug: auto-update silently drops all Remote Control bridges; existing sessions cannot reconnect

Product: Claude Code — desktop app (Windows)
Versions involved: 2.1.2662.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.jsonupdaterLastSeenVersion = "1.52386.6".

The crash queue is emptysentry/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

  1. Enable Remote Control (settings checkbox: future sessions will be connected).
  2. Start two Claude Code desktop sessions in different projects. Confirm both are reachable

via Remote Control from another device.

  1. Let the app auto-update (or restart the application).
  2. Observe: both conversations resume and are fully usable locally.
  3. 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

  1. Re-establish the bridge on startup for sessions that were previously bridged — this is

the actual fix.

  1. Tell the user. Any visible indication ("Remote Control disconnected — reconnect?") turns

a silent, baffling failure into a one-click recovery.

  1. 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.

  1. Prune orphaned bridge-state.json entries whose localSessionId no longer resolves.
  2. 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.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗