[Desktop] Auto-update relaunch drops all Remote Control sessions and they don't reconnect until opened locally

Happened again the next night, on the following update (2.26454.0 → 2.26454.2). Same sequence, so this looks like it reproduces on every auto-update relaunch rather than being a one-off.

Timeline from ~/Library/Logs/Claude/main.log (KST, 2026-10-08):

| Time | Event |
| --- | --- |
| 03:19:01 | last [remote-control] bridge_state: "connected" |
| 03:21:59 | [updater] Found an update, downloading |
| 03:22:17 | [updater] Update downloaded and ready to install { releaseName: 'Claude 2.26454.2' } |
| 03:32:47 | [stealth-relaunch] — app quits itself |
| 03:32:56 | [stealth-relaunch] Version changed since the last launch: loading the saved page instead of restoring history |
| 03:32:59 – 03:33:09 | exactly one Code session is warmed ([CCD] Warming session ... → warmed successfully) |
| 03:33 – 08:45+ | zero Enabling remote control lines and zero [remote-control] bridge_state lines |

Extra observations this time:

• Before the relaunch there were 20+ non-archived Code tab sessions with Remote Control on (remoteControlAutoEligible: true and a bridgeSessionIds entry in each local_*.json). After the relaunch only two session processes exist on the machine: the one warmed at 03:33 and a scheduled-task run that started at 08:13. Every other session has no process, so nothing is holding its Remote Control connection.
• Server side, the sessions' remote counterparts were all flipped to archived at the same instant as the quit (12 of them share updated_at 18:32:47Z, i.e. 03:32:47 KST). So from mobile / claude.ai/code they don't just show as disconnected — they drop out of the default list.
• Un-archiving them through the API brings them back into the list as pending / connection_status: disconnected, but the desktop app does not react to that (nothing in main.log), and they stay disconnected. As far as I can tell there is no way to wake them remotely; the only recovery is opening each session by hand on the machine.
• The [sessions-bridge] path does the right thing at startup (Reconnecting persisted session ... → reconnected successfully within 3 seconds of launch), so the gap seems specific to per-session Remote Control for Code tab sessions.

Expected: after an update relaunch, sessions that had Remote Control connected are re-attached automatically (or at least woken when a remote client sends a message), the same way the persisted bridge session is.

Environment: macOS, Claude Desktop 2.26454.2, bundled Claude Code 2.1.293.

Same here on macOS, and it reproduces on every update relaunch — 4 of the last 4 days.

Environment: Claude desktop 2.31226.1 (Apple Silicon), bundled Claude Code 2.1.295, macOS 27.0. A Mac Studio used unattended via Remote Control from a MacBook / iPhone; 4 Code-tab sessions with remoteControlUserEnabled: true.

Relaunches ([stealth-update] Triggering stealth update after idle timeout, KST): 10-07 04:50 (2.26454.0) · 10-08 03:01 (2.26454.2) · 10-09 13:12 (2.31226.0) · 10-10 05:16 (2.31226.1). After each one the app warms only the focused session and emits no [remote-control] bridge_state line on its own:

| relaunch | RC back | gap | what ended it |
|---|---|---|---|
| 10-09 13:12 | 15:26 | 2h14m | someone touched the app window on the Mac |
| 10-10 05:16 | 11:55 | 6h39m | sessions woken remotely — see below |

Two findings that may help narrow it down:

1. The sessions can be woken without touching the machine, and then reconnect immediately. A terminal claude --remote-control session running in tmux on the same Mac is unaffected by the relaunch (it survived both 10-09 and 10-10). From it, sending a cross-session message to the one app session that was warmed, and having that session use the Code-tab session tools (send_message) to ping the other RC-enabled sessions, made each of them resume and produce a turn — and each reconnected within ~1 s of resuming:

``
11:55:52 Resuming session local_19e1…
11:55:54 [remote-control] bridge_state: "ready"
11:55:55 [remote-control] bridge_state: "connected" (×4 sessions by 11:55:57)
`
So RC registration itself works; what is missing is only that the app does not resume RC-enabled sessions after the relaunch. (open -a Claude` / activating the window remotely does nothing.)

1. The stealth-update gate only checks "sessions active / window focused / window fullscreen" before quitting; "a session has Remote Control on" is not a blocker, and there is no post-relaunch resume step for those sessions.

Expected, as above: after a relaunch, resume (or at least wake on an incoming remote message) every non-archived session that had Remote Control enabled — the app already does the equivalent for the persisted [sessions-bridge] session within 3 s of launch. Same symptom as the stale-closed #77871 (Windows).

Follow-up with code evidence (desktop app 2.31226.1, macOS). Yesterday's stealth update (04:55 KST, [stealth-update] Triggering stealth update after idle timeout) again relaunched the app with 4 sessions that had Remote Control on; none reconnected until a human sent each session a message 5.5 h later.

Looking at app.asar, the restore path already exists: on quit, sessions are tagged remoteControlLiveAtUpdateQuit, and on launch restoreBridgesAtLaunch / restoreBridgeAfterUpdate re-enable RC with trigger launch_remote_control_restore (log line [CCD] Remote Control restore after update: …). In my logs that line has never appeared across 6 update relaunches (10-07 → 10-14); the only trigger ever logged is warm_send. The quit-side tagging is gated (eP() → flag ids 3106428025 + 3188054034), so I assume the feature is dark for my account. Could it be enabled, or at least the gate surfaced? Happy to test a build or share logs.