[BUG] Windows desktop: Remote Control not restored after app relaunch (silent update / restart), sessions show as archived on mobile

Update: why it happens every night

It happened again last night with the same pattern. Windows did not sleep or restart (no System events 42/107/1074/6006 overnight).

01:01:05 [updater] Found an update, downloading
01:11:51 [stealth-update] Triggering stealth update after idle timeout
01:11:51 [CCD] Stopping 8 active session(s) on quit
01:11:56 beforeQuitForUpdate handler fired, going down for update
01:12:34 Starting app {
   ... no "Enabling remote control for session" until the user wakes a session by hand at 10:41 ...

What the shipped bundle shows (2.26454.2)

• The stealth update starts a 10-minute countdown (6e5 ms) once an update is staged and idleBlocker() returns null.
• idleBlocker() blocks only in three cases:
• "sessions active"
• "window focused"
• "window fullscreen"
• Sessions that are idle but connected to Remote Control do not count as active. So the update fires every night while the user is asleep. These are exactly the hours the user relies on Remote Control from the phone.
• After relaunch nothing re-enables Remote Control for the sessions that had it, so they show as archived on mobile.

Workarounds and why they are not enough

• Full screen (F11) blocks the stealth trigger. But autoUpdaterEnforcementHours defaults to 72, so the force-restart still happens within 3 days.
• The disableAutoUpdates policy stops it, but it also stops security fixes.
• remoteControlStayReachable does not help. It only keeps the machine awake for rc-serve; it does not restore existing sessions.

Suggested fix (either would solve it)

1. Persist which sessions had Remote Control on before a quit-for-update and re-enable it after relaunch (the desktop equivalent of the preserve path in #92194).
2. Treat a session with an active Remote Control link as a blocker in idleBlocker(), or let the user schedule when the stealth update may run.

Another occurrence on Windows, with timestamps from %LOCALAPPDATA%\Claude\Logs\main.log (2026-10-09 JST).

Environment

• Windows 11 Home 10.0.26200, Microsoft Store package Claude_2.31226.0.0_x64 (version after the relaunch)
• Claude Code 2.1.266
• Setting "Connect new sessions to Remote Control": On

Timeline

1. 13:32:27 the Code session finishes a turn and goes idle (Remote Control connected)
2. 13:42:27 [stealth-update] Triggering stealth update after idle timeout → [CCD] Stopping 3 active session(s) on quit — Remote Control drops
3. 13:42:32–13:42:36 after the relaunch: [CCD] Warming session <id> → warmed successfully in 3392ms. No Remote Control enable line at this point
4. 13:46:44 only when the user sends a message locally: LocalSessions.sendMessage → Enabling remote control for session <id> → Remote control enabled → [remote-control] bridge_state: "connected"

Expected
Sessions that had Remote Control on before the stealth-update relaunch (and sessions covered by the "On" default) should be reconnected when they are restored/warmed, without waiting for a local message. Otherwise a user controlling the session from the phone or claude.ai/code loses it and cannot get it back remotely. In this case Remote Control was off for about 4 minutes until someone typed on the PC.

Same behavior here, Windows 11, Claude desktop 2.31226.0. After the silent relaunch every Code session came back with Remote Control off, and they stayed that way until each one was opened or messaged on the desktop.

Excerpt from %LOCALAPPDATA%\Claude\Logs\main.log (09 Oct 2026, local time):

2026-10-09 09:40:41 [info] [stealth-update] Triggering stealth update after idle timeout
2026-10-09 09:40:41 [info] [CCD] Stopping 17 active session(s) on quit
2026-10-09 09:40:55 [info] Starting app {
  appVersion: '2.31226.0',

The same pair of lines appears in the same log on earlier days, with the number of stopped sessions in parentheses:

• 03 Oct 01:39 (10 sessions)
• 06 Oct 12:24 (6)
• 07 Oct 17:10 (14)
• 09 Oct 09:40 (17)

Before the relaunch one session had an explicit Remote Control bridge and the app logged "Skipping pause ... remote control is active" every 15 minutes, so the app knew the link was live, yet it still fired the update. This supports the idleBlocker() point above: an active Remote Control link does not count as a reason to postpone the stealth update.

"Connect new sessions to Remote Control" is On in my settings and did not help, since the relaunched sessions are not new.

Another Windows occurrence on the current build, with the server-side state and a recovery that works without sending a turn.

Environment

• Windows 11 Pro 10.0.26200, Microsoft Store (MSIX) install
• Claude desktop 2.31226.0 → 2.31226.1 (the relaunch below), bundled Claude Code 2.1.295
• "Connect new sessions to Remote Control": On. "Archive inactive sessions": Never. "Auto-archive sessions when their pull request closes": Off
• Phone: Claude mobile app (Android)

Timeline (%LOCALAPPDATA%\Claude\logs\main.log, JST, ids redacted)

2026-10-09 18:21:30 [info] Remote control enabled: "https://claude.ai/code/session_<A>"
2026-10-09 18:21:30 [info] [remote-control] bridge_state: "connected"
2026-10-09 19:17:21 [info] [Stop hook] Query completed for session local_<A>
2026-10-10 05:58:42 [info] [updater] Staged version 2.31226.1 is still current (latest: 2.31226.1, lastTarget: null)
2026-10-10 05:59:12 [info] [stealth-update] Triggering stealth update after idle timeout
2026-10-10 05:59:12 [info] [CCD] Stopping 5 active session(s) on quit
2026-10-10 05:59:14 [info] [CCD] CLI exit before update: 5 of 5 exited within 1614ms
2026-10-10 05:59:14 [info] beforeQuitForUpdate handler fired, going down for update
2026-10-10 05:59:16 [info] [updater] Version changed since last launch: 2.31226.0 → 2.31226.1

No Enabling remote control for session line follows for any restored session. remote-control.log at the quit: quit: 0 attached session(s) queued for unarchive, 0 parked for the next launch.

At 08:36 the Android app showed session A with a "session archived" notice in place of the message box (the app is in Chinese: 此会话已归档). On the desktop the session was not archived.

The same [stealth-update] relaunch appears five times in nine days in this log: 02 Oct 17:00, 06 Oct 03:54, 07 Oct 11:22, 08 Oct 03:32 and 10 Oct 05:59 (1, 6, 4, 2 and 5 sessions stopped).

Server-side state after the relaunch (session records, both tagged remote-control-sdk)

| Session | session_status | connection_status | updated_at (UTC) |
|---|---|---|---|
| A | SESSION_STATUS_ARCHIVED | disconnected | 2026-10-09T20:59:12.738Z |
| B, stopped by the same quit | SESSION_STATUS_PENDING | disconnected | 2026-10-09T20:59:12.791Z |

20:59:12Z is 05:59:12 JST, the second the app logged Stopping 5 active session(s) on quit. So the archive is written at quit time, but not for every session that the same quit stops.

Recovery that worked on 2.31226.1 without sending a turn

For a session whose process has not started since the relaunch, the Remote Control switch is still refused, as reported in #95364:

2026-10-10 08:56:27 [warn] Cannot toggle remote control for local_<C>: no active query

Opening the session is enough to change that. No message is needed:

1. Open the session in the app, by clicking it in the sidebar or with Start-Process "claude://claude.ai/epitaxy/local_<C>".
2. Turn its Remote Control switch on. I asked Claude in another Code session to do it (set_remote_control).

2026-10-10 08:59:17 [info] [CCD] Warming session local_<C>
2026-10-10 08:59:17 [info] [CCD] Session local_<C> warmed successfully in 103ms
2026-10-10 08:59:48 [info] Enabling remote control for session local_<C>
2026-10-10 08:59:48 [info] Remote control enabled: "https://claude.ai/code/session_<C, same id as before the relaunch>"
2026-10-10 08:59:49 [info] [remote-control] bridge_state: "connected"

Session A, which had been opened in the sidebar after the relaunch, took the switch directly, and its server record went from ARCHIVED / disconnected back to SESSION_STATUS_IDLE / connected under the same session id.

Both steps also worked from a session that was started from the phone on that computer, so the recovery can be done while away. It is still manual and one session at a time.

Expected

As in the original report: after a relaunch for an update, sessions that had Remote Control connected should get it back without anyone touching them, or the relaunch should wait while a Remote Control link is up. Warming a session and switching Remote Control on already restores the same claude.ai session, so doing that at launch for the sessions that were connected at quit would close the gap.