Desktop auto-update ("stealth update") quits and relaunches the app while the user is away, dropping every Remote Control session

Environment

• Claude Desktop 2.2553.1 (macOS 26.6.2, Apple Silicon)
• Bundled Claude Code 2.1.275
• Remote Control in use daily from claude.ai/code while away from the machine

Summary

When an update is staged, the app waits for a short idle window and then quits and relaunches itself. It logs this as [stealth-update]. The relaunch stops every running Code session and drops each session's Remote Control link.

For a user sitting at the machine this is nearly invisible, which is presumably the intent. For a user working remotely it is the opposite of invisible: the restart fires precisely when nobody is at the keyboard, which is exactly when Remote Control is the only way in. Every time I open my laptop while travelling, Remote Control has disconnected and the app has restarted itself.

What the app logs

From ~/Library/Logs/Claude/main.log, one complete cycle:

09:47:53 [info] [updater] Update downloaded and ready to install { releaseName: 'Claude 2.2553.1' }
10:21:28 [info] [stealth-update] Triggering stealth update after idle timeout
10:21:28 [info] [remote-tools-device] close
10:21:28 [info] [CCD] Stopping 3 active session(s) on quit
10:21:30 [info] [CCD] CLI exit before update: 3 of 3 exited within 1772ms
10:21:31 [info] beforeQuitForUpdate handler fired, going down for update
10:21:54 [info] Starting app { ... }
10:21:54 [info] [updater] Version changed since last launch: 2.2553.0 → 2.2553.1

Squirrel's own log for the same moment (~/Library/Caches/com.anthropic.claudefordesktop.ShipIt/ShipIt_stderr.log):

10:21:31 Beginning installation
10:21:40 Moved bundle contents ... to file:///Applications/Claude.app/
10:21:49 Successfully launched application at file:///Applications/Claude.app/

Trigger conditions

The updater's own gate lists four things that block a stealth update:

1. the same version having failed to install repeatedly
2. an actively running session
3. the window being focused
4. the window being fullscreen

None present → a timeout starts, and the update fires when it elapses. Measured on this machine: the update was staged at 09:47:53, the last session activity was at 10:11:39, and the update fired at 10:21:28 — roughly ten minutes after the machine went quiet.

Those three blockers are exactly the conditions that are absent for a remote user. An idle-but-connected Remote Control session is, from the updater's point of view, indistinguishable from an abandoned machine.

Regression window and frequency

Every Triggering stealth update across all retained logs on this machine:

2026-08-27 04:43:59
2026-08-28 19:24:07
2026-09-01 22:06:16
2026-09-03 07:39:40
2026-09-08 22:03:42
2026-09-15 22:23:46
2026-09-17 07:35:19
2026-09-18 03:46:49
2026-09-18 10:21:28

The oldest retained log begins 2026-08-12 and contains no stealth updates before 2026-08-27. So the behaviour appears to have started around 27 August, and the rate has risen since: nine restarts in 22 days, two of them on a single day.

Impact

• Every running Code session is stopped mid-flight.
• Per-session Remote Control connections are dropped and do not come back after the relaunch, even with "Connect new sessions to Remote Control" set to On — restored sessions are not treated as new. (The device-level bridge does reconnect on its own; it is the per-session links that are lost.)
• MCP servers are torn down and some fail to reconnect on the way back up, producing a cluster of error notifications on each relaunch.
• The user has no way to know it happened until they try to reconnect and find the session gone.

Suggested fixes, in order of preference

1. Add "any session connected to Remote Control" to the blocker list. A machine with a live Remote Control link is not idle; someone is just not physically present. This alone would resolve the reported problem.
2. Re-establish per-session Remote Control after a stealth relaunch. The app already restores navigation history and window state across the relaunch, so the session identifiers are available.
3. Offer a user setting to defer stealth updates, comparable to the existing keep-awake and notification preferences. There is currently no supported way to turn this off or postpone it.

Fix 1 is the smallest and addresses the asymmetry directly: the feature is named for being unobtrusive, and the one class of user it obtrudes on is the one who cannot see the machine.

15:41:11 [updater] Update downloaded and ready to install { releaseName: 'Claude 2.7032.0' }
20:33:58 last turn ends
20:43:58 [stealth-update] Triggering stealth update after idle timeout   <- exactly 600 s later
20:43:58 [CCD] Stopping 9 active session(s) on quit

14:02:56 [stealth-update] Triggering stealth update after idle timeout
14:02:59 beforeQuitForUpdate handler fired, going down for update
14:02:57 [CCD] Stopping 3 active session(s) on quit
14:03:12 [CCD] Initialized with version 2.1.280
14:03:12 [stealth-relaunch] Detected via marker file (windowVisible=true)
14:03:12 [updater] Version changed since last launch: 2.2553.1 -> 2.7032.0