[BUG] Desktop app: Remote Control silently turns off on every app relaunch – bridge session is never reconnected

What's Wrong?

Remote Control on a Desktop app Code session doesn't survive an app relaunch. After a restart the toggle is off again – no notice, no log line about disabling. Since every app update means a relaunch, this happens constantly – I first suspected compaction, until the logs pointed at the relaunches.

This isn't me forgetting to enable it – I have the auto-enable preference on, and it fires automatically when a session starts fresh:

Starting local session local_…
[rcAutoEnable] verdict: enable=true source=explicit_pref
Enabling remote control for session local_…

But rcAutoEnable only fires on Starting local session. Restart-restored sessions are restored, not started, so the auto-enable path never runs for them – their pre-restart bridge is dead, and nothing re-arms it.

What the logs and on-disk stores show:

• Per-session Remote Control state is runtime-only. Each enable mints a fresh bridge session (Remote control enabled: https://claude.ai/code/session_01…)
• On startup the app reconnects only the account-level bridge session persisted in bridge-state.json ([sessions-bridge] Reconnecting persisted session cse_…) – that entry carries an explicit "enabled": true, and no session_01… id ever appears in the log again after a relaunch
• The per-session store (claude-code-sessions/…/local_*.json) keeps past ids in bridgeSessionIds, but no equivalent flag

This isn't idle expiry either: across three weeks of logs (~85 Remote Control bridge sessions), not one ever publishes again after an app restart, while publishing routinely survives overnight idle gaps within a single app run – and one session logged 34 active turns between an app restart and my manual re-enable without a single publish.

What Should Happen?

Restored sessions should re-run the auto-enable path the same way freshly-started ones do – or the persisted per-session enablement should be reconnected on startup, the way the account-level cse_… bridge already is. Failing either, the toggle turning itself off should at least be surfaced to the user.

Error Messages/Logs

# Enable (user action) – ~/Library/Logs/Claude/main.log
2026-07-17 07:51:51 [info] Enabling remote control for session local_<uuid>
2026-07-17 07:51:53 [info] Remote control enabled: https://claude.ai/code/session_01<id A>
2026-07-17 08:41:15 [info] handoff: publishing session_01<id A>   # last sign of life

# Cmd+Q and reopen – only the account-level bridge session comes back
2026-07-17 08:47:16 [info] Starting app {
2026-07-17 08:47:18 [info] [sessions-bridge] Initializing bridge { oauthEnv: 'production', … }
2026-07-17 08:47:19 [info] [sessions-bridge] Reconnecting persisted session cse_01<id>
2026-07-17 08:47:20 [info] [sessions-bridge] Session cse_01<id> reconnected successfully
# session_01<id A> never appears again – no reconnect attempt, no disable line anywhere

Steps to Reproduce

1. In the Desktop app (macOS), open a Code session and enable Remote Control – the claude.ai/code/session_01… link works, and main.log logs handoff: publishing session_01… on every turn
2. Quit the app (Cmd+Q) and reopen it – an update relaunch does the same
3. Reopen the session: The Remote Control toggle is off and the remote session is dead
4. ~/Library/Logs/Claude/main.log shows only Reconnecting persisted session cse_… at startup, never any session_01…

I ran this deliberately, with three sessions enabled at once – two actively publishing (50 and 42 publishes), one idle. After the restart all three toggles were off, none of the three session_01… ids appears in the log again, and the only bridge line at startup is the cse_… reconnect – with the three store files still listing their now-dead bridge ids unchanged.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.209 (embedded in Desktop app 1.22209.0)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other (Desktop app Code tab)

Additional Information

Related issues:

• #70602 – reports the "enable for all sessions" preference being ignored for new sessions. On this build it isn't ignored – new sessions fire rcAutoEnable (… source=explicit_pref) and mostly get a live bridge. What fails outright here is narrower: restored-after-restart sessions never reach that path at all. Possibly the current-build shape of its first failure mode – happy to have it merged if a maintainer agrees
• #66491 (closed as stale) – Desktop app not reattaching sessions after a WiFi drop. Different trigger, apparently the same gap, and it reports the same Desktop-vs-CLI split
• #36261 (persistence feature request), #76070/#77985 (CLI, session dies with the process), #34255/#33041 (live connections dropping mid-session)