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.

Start by reviewing the reported ~/Library/Logs/Claude/main.log and ShipIt_stderr.log cycle, focusing on the stealth-update trigger and the Remote Control close events. Trace the updater's idle blockers and the active-session entry point. Done means an active Remote Control connection prevents the stealth relaunch, with tests or logs showing that running sessions are not dropped.

Written by the indexing model from the issue text.