Remote Control silently disconnects on sessions-bridge re-initialization; enabled sessions are never persisted

Summary

Remote Control auto-enables correctly when a new desktop-app session is created. But when the sessions-bridge re-initializes, every session that currently has Remote Control enabled is dropped — with no log entry, no notification, and no UI indication. The per-session toggle silently flips to off and the session disappears from the mobile app.

The apparent cause: Remote Control sessions are never written to bridge-state.json, which is the store the bridge reads from on init (Reconnecting persisted session). Only one entry exists in that file, so only that one session is restored and all the others are lost.

Because nothing is logged and nothing is surfaced, the user has no way to learn the session went offline except by opening the desktop app and visually checking each toggle — which defeats the purpose of remote access.

Environment

| Item | Value |
|---|---|
| Desktop app | 1.28929.0 (Windows) |
| Bundled CLI | 2.1.227 |
| OS | Windows 11 Pro 10.0.26200 |
| Subscription | Max |
| Setting | remoteControlAtStartup: true (user scope, ~/.claude/settings.json) |
| Relevant flags | tengu_ccr_bridge=true, tengu_bridge_selfheal_heartbeats=true, tengu_bridge_recover_stale_epoch=false |

Identifiers below are redacted; happy to supply the raw values privately.

Steps to reproduce

1. Set remoteControlAtStartup: true at user scope.
2. Create several desktop-app sessions. Each logs Enabling remote control → bridge_state: connected and becomes visible on mobile. (Confirmed 7/7 on the observed day.)
3. Trigger a sessions-bridge re-initialization. In the observed case this followed a transient DNS failure resolving bridge.claudeusercontent.com, after which the account context dropped to <none> and was re-evaluated.
4. Inspect the Remote Control toggle on the sessions that were created before the re-init.

Expected: Previously-enabled sessions reconnect after the bridge re-initializes — or, at minimum, the user is told they were disconnected.

Actual: They are silently dropped. Toggle shows off, no log line is written, and they are gone from the mobile app.

Evidence

All timestamps KST, from %APPDATA%\Claude\logs\main.log on 2026-08-12.

The re-initialization, restoring exactly one session:

14:18:26 [info] [sessions-bridge] account-change reevaluate: <none> → <org>:<workspace>
14:18:26 [info] [sessions-bridge] Initializing bridge { oauthEnv: 'production', apiHost: 'https://api.anthropic.com', … }
14:18:26 [info] [sessions-bridge] Registering environment (reusing env_REDACTED)...
14:18:28 [info] [sessions-bridge] Environment registered: env_REDACTED
14:18:29 [info] [sessions-bridge] Reconnecting persisted session cse_REDACTED
14:18:29 [info] [sessions-bridge] Session cse_REDACTED reconnected successfully

Three Remote Control sessions were connected at that moment. None appears in the reconnect path.

A representative enable, showing state that later vanishes:

13:12:54 [info] Starting local session local_188c2c44-… in <cwd>
13:12:55 [info] Enabling remote control for session local_188c2c44-…
13:13:02 [info] [remote-control] bridge_state: ready
13:13:02 [info] Remote control enabled: https://claude.ai/code/session_REDACTED
13:13:03 [info] [remote-control] bridge_state: connected

After this there is no further remote-control log line for this session for the rest of the day — no disable, no teardown, no reconnect attempt — yet the toggle is now off.

The persistence store, holding one entry for the day's eight enabled sessions:

// %APPDATA%\Claude\bridge-state.json — complete contents
{
  "<org>:<workspace>": {
    "enabled": true,
    "userConsented": true,
    "environmentId": "env_REDACTED",
    "localSessionId": "local_ditto_<org>",
    "remoteSessionId": "cse_REDACTED",
    "processedMessageUuids": [],
    "pendingProcessedAcks": []
  }
}

Correlation with the re-init boundary. All eight sessions land on the expected side — the four before the re-init are off, the four after are still connected:

| Enabled at | Session | Relative to 14:18 re-init | Toggle state now |
|---|---|---|---|
| 11:17 | local_48aa2249 | before | off |
| 13:13 | local_188c2c44 | before | off |
| 13:13 | local_f8a2086c | before | off |
| 13:36 | local_382956d8 | before | off |
| — | bridge re-init 14:18:26 | — | — |
| 15:10 | local_de414ae3 | after | on |
| 18:13 | local_f1ac445e | after | on |
| 18:15 | local_32dff94c | after | on |
| 20:14 | local_a02f869d | after | on |

Ruled out

• Network outage alone is not the trigger. The session enabled at 15:10 survived DNS failures at 17:51–18:03 and 18:47–18:48 and is still connected. Those outages produced no Initializing bridge line.
• Process restart is not the trigger. local_382956d8 (enabled 13:36:43) still owns its original CLI process — started 13:36:45, never respawned — and lost Remote Control anyway.
• Sleep/resume is not the trigger. At 20:09:27 the log shows [sessions-bridge] System resumed; waking poll loop with no re-initialization, and sessions on the post-14:18 side survived it.
• Idle teardown / re-warm is not the trigger. local_188c2c44 was torn down and re-warmed eight times between 20:16 and 20:39 (WarmLifecycle:preview Warming up session …) with no reconnect attempted on any of them — but sessions on the post-14:18 side went through the same cycle and stayed connected.

The only event that correlates is the bridge re-initialization.

Impact

• Remote access fails silently. The failure mode is invisible from the remote side, which is exactly where the user is when they need it.
• Recovery requires physical access to the desktop machine to re-toggle — the situation Remote Control exists to avoid.
• Restarting the app does not help; app startup performs the same re-init and would drop any still-connected sessions.

Suggested fixes

1. Persist Remote Control sessions to bridge-state.json and include them in the Reconnecting persisted session path on bridge init. (Primary fix.)
2. Log teardown. Emit a disable/teardown line whenever a Remote Control session is dropped, so the failure is diagnosable at all.
3. Surface it. Notify the user, or reflect the disconnected state somewhere reachable remotely rather than only in the desktop toggle.

tengu_bridge_recover_stale_epoch is currently false for this account; if that flag governs post-outage bridge recovery, it may be worth checking whether it interacts with this path.

Related observation (separate, lower priority)

Forked sessions never auto-enable Remote Control even with remoteControlAtStartup: true — LocalSessions.forkSession produces no Enabling remote control. This may be intentional, but it is undocumented and surprising.