[BUG] Desktop app auto-update kills local sessions AND remote-tools-device connection; local session list stays empty after relaunch even though the session reconnects server-side (Remote Control shows "archived" on mobile)

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

Every time the Claude Desktop app (Electron) auto-updates overnight, it silently quits and relaunches. On relaunch, the underlying session reconnects successfully at the protocol level (visible in the logs), but the app's own local session list is empty, and the Claude mobile app shows the session as "archived." I have to physically go to the Mac and manually reconnect from the desktop app before the session becomes usable again from my phone — this defeats the purpose of always-on remote access.

This happens roughly every 1-3 days (whenever an auto-update lands), on a Mac mini I leave running 24/7 specifically to use as a persistent Remote Control host.

### What Should Happen?

After an auto-update relaunch, a session that reconnects successfully server-side (confirmed in logs: "[sessions-bridge] ... reconnected successfully") should also reappear in the app's own local session list, and remain reachable/usable from the mobile app without requiring physical access to the host machine.

### Error Messages/Logs

```shell
From ~/Library/Logs/Claude/main.log, most recent occurrence (2026-09-16, KST):

[updater] Found an update, downloading
[updater] Update downloaded and ready to install { releaseName: 'Claude 2.110.0' }
[updater] Version changed since last launch: 1.52386.6 -> 2.110.0
[updater] Previous update install succeeded (1.52386.6 -> 2.110.0)

On quit-to-update, local sessions AND the remote tool-execution channel are torn down together:
[remote-tools-device] close
[CCD] Stopping 4 active session(s) on quit
Stopping session local_
Running onQuitCleanup: remote-tools-device-cleanup
Running onQuitCleanup: remote-server-cleanup
Running onQuitCleanup: local-session-stop-all

On relaunch, the persisted session reconnects at the protocol/backend level:
[sessions-bridge] Initializing bridge { oauthEnv: 'production', apiHost: 'https://api.anthropic.com', ... }
[sessions-bridge] Reconnecting persisted session cse_
[sessions-bridge] Session cse_ reconnected successfully
[sessions-bridge] Handling session work { sessionId: 'cse_', workId: 'cse_' }
[sessions-bridge] Session work received, waiting for user message via transport

But in the same window, the app's own local session manager reports zero sessions:
[LocalAgentModeSessionManager] Initialization succeeded — accountId=, orgId=, existingSessions=0
[LocalSessionManager] Initialization succeeded — accountId=, orgId=, existingSessions=0

The remote-tools-device channel also reconnects independently and keeps cycling afterward:
[remote-tools-device] connecting wss://bridge.claudeusercontent.com
[remote-tools-device] connect frame sent: device_id keyed
[remote-tools-device] authenticated
[remote-tools-device] socket closed: 1006
[remote-tools-device] reconnect #1 in 3221ms
```

### Steps to Reproduce

1. Leave the Claude Desktop app running on a Mac that stays powered on 24/7 (no sleep preventing background operation).
2. Keep at least one session active with Remote Control enabled, and access it periodically from the Claude mobile app.
3. Wait for an overnight auto-update to land (happens roughly every 1-3 nights based on my own logs — 4 out of the last 6 nights, version jumps like 1.52386.0 -> 1.52386.3 -> 1.52386.6 -> 2.110.0).
4. The next time you open the mobile app, the session shows as archived / not connected.
5. Reconnecting requires physical access to the Mac (open the desktop app, which then shows the session again).

I can't provide a minimal isolated repro since this depends on the app's own auto-update timing, but the log excerpts above show the exact sequence of events each time it happens.

### Claude Model

None

### Is this a regression?

No, this never worked

### Last Working Version

_No response_

### Claude Code Version

2.110.0 (Claude Desktop app version — did not check the CLI's `claude --version` separately, since this bug is about the Desktop app itself, not the CLI)

### Platform

Other

### Operating System

macOS

### Terminal/Shell

Other

### Additional Information

This is specifically about the macOS Desktop app (Electron), not the CLI. The Desktop app's own internal version at the time of this report was 2.110.0 (per its updater logs), which is a separate version scheme from `claude --version`.

Related existing issues (similar symptom, but neither covers this specific gap — the session reconnects server-side while the local/mobile-facing session list does not reflect that):
- #85413 — Desktop auto-update relaunches the app and silently kills live session hosts, no way to disable
- #86084 — Remote Control silently disconnects on sessions-bridge re-initialization; sessions not persisted to bridge-state.json

Requesting either: (1) a fix so the local session list properly rehydrates from a server-side-reconnected session after an update relaunch, or (2) an official, documented way to defer/control auto-updates on the Desktop app specifically (the CLI's DISABLE_AUTOUPDATER setting does not affect the Desktop app's separate updater).

Start with ~/Library/Logs/Claude/main.log and trace the updater quit cleanup, sessions-bridge persisted-session reconnect, LocalSessionManager initialization, and remote-tools-device reconnect sequence. There is no source file or test named in the report; done means an auto-update relaunch leaves the reconnected session in the local list and usable from mobile without physical reconnection, or documents a supported way to control updates.

Written by the indexing model from the issue text.