[BUG] Desktop app (Windows): Remote Control bridge never re-arms after an app restart/auto-update — session goes silent on mobile for hours and shows as archived, until the user types in the desktop app

Preflight Checklist

• [x] I have searched existing issues. The closest are #92194 (CLI claude remote-control archives sessions after a network give-up) and #75573 (Windows auto-update losing the session index). This one is a different mechanism: the desktop app's own Remote Control bridge simply never reconnects after the app restarts, and nothing archives anything locally.
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

On the Windows desktop app, the Remote Control bridge does not come back by itself after the app restarts — including the restarts the app performs for its own Claude Code auto-update. The bridge stays down until the user types something into the session in the desktop app; the only rcAutoEnable trigger I ever see in the logs is warm_send.

Consequences for a long-running session that is being watched from the phone:

• Everything the session produces while the bridge is down never reaches the mobile app / claude.ai/code. For an overnight run that is the entire night's output.
• On the phone the session then presents as archived, even though locally it is not. Querying the session on the desktop side reports isArchived: false, pinned: true, remoteControlState: "on", remoteControlActive: true, and the local log has no archive event for it at all (the only Archived session line in 8.5 MB of main.log is a different session from a week earlier). So the archived state the user sees is purely a consequence of the bridge being gone.
• Because the app auto-updates roughly daily and often in the early morning, this happens most nights. Pinning the session does not help.

Measured from one machine's main.log — each app restart followed by the next time the bridge actually reached connected:

| App restart (sessions-bridge identity reevaluate: <none> → …) | Next [remote-control] bridge_state: "connected" | Gap |
|---|---|---|
| 2026-10-07 04:05:45 (auto-update → 2.1.289) | 08:35:54 | 4 h 30 m |
| 2026-10-08 02:16:33 (auto-update → 2.1.293) | 07:22:08 | 5 h 06 m |
| 2026-10-09 07:27:26 | 22:20:40 | 14 h 53 m |
| 2026-10-10 04:38:15 (auto-update → 2.1.295) | 07:53:01 | 3 h 15 m |

Every one of those reconnects is immediately preceded by [rcAutoEnable] verdict: enable=true source=user_intent trigger=warm_send — i.e. the user typing in the desktop app. There is no restart-time re-arm.

What Should Happen?

After an app restart — and especially after an auto-update-driven restart — a session whose Remote Control was on should have its bridge re-established automatically, without waiting for the user to send a message locally. Failing that, the mobile side should distinguish "bridge down" from "archived", because they look identical to the user today and the recovery actions are completely different.

Error Messages/Logs

%LOCALAPPDATA%\Claude\Logs\main.log, session id shortened:

2026-10-09 22:20:38 [info] [rcAutoEnable] verdict: enable=true source=user_intent trigger=warm_send
2026-10-09 22:20:39 [info] [remote-control] bridge_state: "ready"
2026-10-09 22:20:40 [info] [remote-control] bridge_state: "connected"
          ... session runs all night, producing output ...
2026-10-10 04:38:07 [info] [remote-tools-device] close
2026-10-10 04:38:13 [info] [SessionMedia] claude-media:// protocol registered          <- app restarting
2026-10-10 04:38:15 [info] [sessions-bridge] identity reevaluate: <none> → <identity>
2026-10-10 04:38:25 [info] [CCD] Decompressed to 259509920 bytes (payload sha256 a300127…)
2026-10-10 04:38:25 [info] [CCD] Installed at …\claude-code\2.1.295\d2e29494ec83\claude.exe
2026-10-10 04:38:25 [info] [CCD] Removing old version: 2.1.289
2026-10-10 04:38:25 [info] [CCD] session spawn on required_version:2.1.295:…
2026-10-10 04:38:26 [info] [CCD] Session local_4d1ef0e2-… warmed successfully in 6798ms
          ... 3 h 15 m with no [remote-control] line at all; phone shows the session as archived ...
2026-10-10 07:52:59 [info] [rcAutoEnable] verdict: enable=true source=user_intent trigger=warm_send
2026-10-10 07:53:00 [info] [remote-control] bridge_state: "ready"
2026-10-10 07:53:01 [info] [remote-control] bridge_state: "connected"

Note the session itself is re-spawned and warmed successfully on the new binary at 04:38:26 — the local session is fine throughout. Only the bridge is missing.

Steps to Reproduce

1. Windows desktop app, a session with Remote Control on, confirmed connected in main.log.
2. Start work that runs for several hours without the user typing anything in the desktop app (a long batch job, an overnight task).
3. Let the app restart during that window — an auto-update will do it on its own, or quit and relaunch the app.
4. Watch the session on the phone: new output stops arriving at the restart, and the session shows as archived there.
5. On the desktop, the session is still running and still reports remoteControlState: "on" / isArchived: false; main.log has no [remote-control] line after the restart.
6. Type anything into the session in the desktop app → trigger=warm_send → bridge reconnects and the phone works again.

Environment

• Claude desktop app 2.31226.1 (Windows MSIX), Windows 11 Pro 26200
• Bundled Claude Code 2.1.295 (the gap reproduced on 2.1.289, 2.1.293 and 2.1.295)
• Session: local, not remote, not a worktree, pinned, permissionMode: auto

Is this a regression?

Not sure / don't know