[BUG] Remote Control is not restored for sessions killed by a stealth auto-update

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When the desktop app applies a stealth auto-update, it stops every running Claude Code session and relaunches. After the relaunch the session records are restored and even warmed, but none of them are started — and Remote Control auto-connect is bound to session start, not to restore.

The result: sessions that had Remote Control active before the update come back unreachable from mobile / claude.ai, silently, with no indication anything was lost. In my case every session stayed disconnected for ~10 hours overnight (23:11 -> 09:00).

Every one of the 12 auto-connect events in my last three days of logs follows the same pairing:

Starting local session local_XXXX...
Enabling remote control for session local_XXXX...
Restore/warm never triggers it, so an update relaunch always drops the connection.

There is no remote workaround:

set_remote_control refuses a stopped session — "Remote Control requires an active session. Send a message first." It only queues the request for that session's next turn.
The session cannot run a turn, because reaching it from mobile is exactly what broke.
A scheduled task cannot bridge the gap — sending a message to another session is "Unavailable in unattended sessions (scheduled-task runs ...), and cannot deliver to them either."
So recovery requires physically sitting at the desktop.

Contributing factor: the stealth update proceeded even though those sessions had declined 8 consecutive idle pauses specifically because Remote Control was active. If a session is actively serving Remote Control, that seems like a signal the update should respect or defer on — the same way background update checks already defer with "Host busy; deferring background update checks".

Environment:

Claude Desktop 2.2553.0 -> 2.2553.1 (MSIX / Windows Store install)
Claude Code (CCD) 2.1.275
Windows 11 Pro 10.0.26100
Setting "Connect new sessions to Remote Control" is ON (ccRemoteControlDefaultEnabled: true)

What Should Happen?

After an update relaunch, sessions that had Remote Control active before the restart should be reconnected automatically — either by restarting those sessions, or by re-attaching Remote Control as part of the restore path rather than only at session start.

At minimum the user should be told the connection was dropped, instead of finding out hours later that the session was unreachable the whole time.

Error Messages/Logs

All from %LOCALAPPDATA%\Claude\logs\main.log

Before the update — sessions repeatedly declining idle pauses BECAUSE Remote Control was active:

23:03:55 [WarmLifecycle:session] Session local_bc418d0c... has declined 8 consecutive idle pauses - its process is not being reaped 23:03:55 [CCD] Skipping pause for session local_bc418d0c... - remote control is active (startup-policy bridge)

The stealth update fired anyway:

23:11:22 [stealth-update] Triggering stealth update after idle timeout 23:11:22 [remote-tools-device] close 23:11:22 [CCD] Stopping 3 active session(s) on quit 23:11:25 beforeQuitForUpdate handler fired, going down for update 23:11:28 [updater] Version changed since last launch: 2.2553.0 -> 2.2553.1

After relaunch — restored and warmed, but never started, and no remote control:

23:11:31 Loaded 47 persisted sessions from ...\claude-code-sessions... 23:11:32 [CCD] Warming session local_2846b5de... 23:11:32 [CCD] Replayed 27 session permission update(s) for local_2846b5de... allowedTools=34

No "Enabling remote control" line follows. The device bridge itself reconnected fine, so this is not a transport problem — no session was re-attached to it:

23:11:32 [remote-tools-device] connecting wss://bridge.claudeusercontent.com 23:11:32 [remote-tools-device] authenticated

Remote Control only returned when I manually opened a NEW session the next morning:

09:00:46 Starting local session local_dc7d2915... in C:
09:00:46 Enabling remote control for session local_dc7d2915...

Steps to Reproduce

On the Windows desktop app, enable Settings -> Claude Code -> "Connect new sessions to Remote Control".
Start one or more local Claude Code sessions and confirm Remote Control is active (visible on claude.ai/code and in the log as "Enabling remote control for session ...").
Leave the machine idle while an app update is staged. The log shows it waiting: [updater] Staged version 2.2553.1 is still current (latest: 2.2553.1, lastTarget: null)
Wait for the idle-triggered update in %LOCALAPPDATA%\Claude\logs\main.log: [stealth-update] Triggering stealth update after idle timeout
After the app relaunches, check the log and the session list.
Observed: the sessions are restored and warmed, but there is no Starting local session and no Enabling remote control for any of them. Remote Control is off for every session and they are unreachable from mobile until opened manually at the desktop.

Expected: the sessions that had Remote Control active are reconnected.

Note: step 4 depends on an update actually being staged, so the timing is opportunistic rather than on-demand. The relevant code path is the update relaunch / session restore, which should be reproducible directly by forcing an update relaunch with active Remote Control sessions.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.2553.1 (c38127)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

No response

Start with the update relaunch and session restore path, using the main.log entries in the report to trace warming versus session start. Compare the restore flow with the logged Remote Control attach during new-session startup. Done means previously connected sessions reconnect after relaunch, or users are clearly told that Remote Control was dropped.