Desktop restart destroys every Remote Control session bridge with no recovery and no notice

### 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

(Related but distinct: #73565 covers the standalone `claude rc` bridge rotating its environment id. This is about the desktop app's per-session bridges being destroyed on restart.)

### What's Wrong?

When Claude Desktop restarts, every live Claude Code session and its Remote Control bridge is destroyed, and nothing re-establishes them. Navigation history *is* restored, so the desktop sidebar still shows every conversation and looks completely normal — while the phone's session list is empty. Nothing is shown on either device to say the bridges are gone.

The sessions are all still *eligible*: every persisted session file under `claude-code-sessions/…/local_*.json` carries `remoteControlAutoEligible: true` with no `remoteControlUserToggled`, so the policy would pass for all of them. There is simply no trigger at session load. `maybeAutoEnableRemoteControl` is only reached from `finishInitialEnqueue` (`first_turn` / `cold_resume`), from `runRemoteControlPassOwedToTurn`, and from `sendMessage` (`warm_send`) — all of which require an inbound turn.

The updater already tries to avoid disrupting work:

```
if (i && Ip() < 600) { … } // user active in the last 600s
if (pTt()) { "[updater] Deferring auto-restart after %d hours: Claude is working" }
```

but `hasActiveClaudeWork()` tests whether a turn is *running*. A session that is bridged to a phone and sitting idle is not "working" by that test, so the restart proceeds and the bridge dies. That is the gap — liveness is measured as compute, not as an attached remote client.

I operate this machine from a phone most of the working day. Every desktop restart — roughly weekly, never at a time of my choosing — makes every conversation unreachable from the phone. Because the Mac looks fine, it took two separate investigations to work out what was happening.

### What Should Happen?

In priority order:

1. **Re-bridge on startup.** At session load, run a Remote Control pass for any session that held a bridge when the app quit. The eligibility flag is already persisted and the sessions are already restored to the sidebar, so the state needed is all there.
2. **Failing that, make the loss visible.** Show a notice on the desktop, or mark the affected sessions as disconnected on the phone rather than omitting them. Silent loss is worse than the loss itself.
3. **Count attached remote clients as active work** in the updater's deferral check, so an unattended restart doesn't tear down a session someone is using from another device.

### Error Messages/Logs

From `~/Library/Logs/Claude/main.log`, an update restart on 9 September:

```
22:07:17 [info] Running onQuitCleanup: local-session-stop-all
22:07:17 [info] [CCD] Stopping 10 active session(s) on quit
22:07:17 [info] Stopping session local_047dad90-…
… (ten of these)
22:07:28 [info] Starting app { appVersion: '1.49585.0' }
22:07:29 [info] [update-restart] Detected nav-restore marker, launching normally
22:07:29 [info] [stealth-relaunch] Loaded navigation history (50 entries, active=49)
22:07:29 [info] [updater] Previous update install succeeded (1.46388.4 -> 1.49585.0)
22:07:29 [info] [stealth-relaunch] Restoring navigation (50 entries, active=49, dropped=0)
```

Ten bridged sessions destroyed, navigation restored, no bridge restored. For the following ten hours the log contains no `rcAutoEnable` pass for any of them.

Repairing one by hand the next morning, by opening it and sending a message:

```
08:31:34 [info] [rcAutoEnable] verdict: enable=true source=explicit_pref trigger=cold_resume
08:31:34 [info] Enabling remote control for session local_558019ca-…
08:31:35 [info] [remote-control] bridge_state: "connected"
```

That is the entire repair — one message per conversation, reconnecting in about two seconds. All ten were restored this way in roughly 20 seconds. The state is recoverable; it is just never recovered automatically, and I'm never told it needs recovering.

### Steps to Reproduce

1. On the desktop, open several Claude Code conversations with Remote Control bridged (the default here — `ccRemoteControlDefaultEnabled` is set, so each new session auto-enables with `source=explicit_pref`).
2. Leave them idle but bridged.
3. Let the app restart — an update install, a managed-config relaunch, or a manual quit all reproduce it.
4. Open the Claude app on the phone.

Expected: the conversations are still listed and reachable, or at minimum something says they aren't. Actual: the list is empty, and the Mac gives no indication anything changed.

### Claude Model

Opus 5 (not model-dependent)

### Is this a regression?

Partly — it's better than it was, but the core problem is unchanged.

An investigation on this machine on 17 August 2026 found the then-current build only ever evaluated the Remote Control policy at session creation (`first_turn`), so a resumed session could never re-bridge at all. 1.49585.0 has added `cold_resume` and `warm_send`, which makes the manual repair above possible — a genuine improvement. What has never worked is any automatic recovery after a restart, or any notice that one is needed.

### Last Working Version

Not known to have worked.

### Environment

| | |
|---|---|
| App | Claude Desktop 1.49585.0 (previously 1.46388.4) |
| Claude Code | CCD 2.1.260 |
| OS | macOS 15.6, arm64 (Mac mini, always on) |
| Subscription | Max |

Start by tracing session restoration around claude-code-sessions/…/local_*.json and the named entry points: finishInitialEnqueue, maybeAutoEnableRemoteControl, runRemoteControlPassOwedToTurn, sendMessage, and hasActiveClaudeWork. Use the restart logs and the manual cold_resume repair as the baseline. Done means idle bridged sessions recover after restart, or the loss is clearly surfaced to users.

Vom Indexierungsmodell aus dem Issue-Text verfasst.