[BUG] Remote Control auto-connect (toggle) dies after an overnight idle; only a manual /remote-control re-arms the shared bridge

Preflight Checklist

• [x] I have searched existing issues 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?

Claude Code embedded in the Claude Desktop app (Windows), with Settings -> Claude Code -> "Enable remote control by default" (ccRemoteControlDefaultEnabled) ON for ~5 days and working normally.

After an overnight idle period - machine powered on the WHOLE night, with NO sleep and NO restart (first time it has ever glitched):

• ALL sessions that had been auto-connected via the toggle dropped to "disconnected" in the Claude mobile app.
• The toggle ALSO stopped auto-connecting NEWLY created sessions. So the shared auto-connect layer failed globally, not per-session.

Recovery only happened after running /remote-control manually in ONE session: that re-armed the shared layer and the toggle began auto-connecting new sessions again. Sessions that had already dropped stayed disconnected and each had to be /remote-control'd individually.

What Should Happen?

The shared Remote Control auto-connect layer should self-refresh / recover after a long (overnight) idle period, so toggle-connected sessions stay connected (or transparently reconnect) without needing a manual /remote-control to "kick" the shared registration back to life. New sessions should also keep auto-connecting without that manual step.

Error Messages/Logs

From /debug logs of the one live session that survived (illustrating the transport layer). The broken auto-connect sessions logged ZERO CCRClient / SSETransport / heartbeat activity at all:

[WARN]  CCRClient: Heartbeat failed: The operation timed out.
[ERROR] SSETransport: Connection error: Unable to connect. Is the computer able to access the url?
[ERROR] SSETransport: Liveness timeout, reconnecting
SSETransport: Reconnecting in 9562ms (attempt 4)

Steps to Reproduce

Intermittent / time-triggered, so hard to force on demand, but the pattern is:

1. Enable Settings -> Claude Code -> "Enable remote control by default".
2. Create several sessions; confirm they auto-connect and appear at claude.ai/code or in the Claude mobile app.
3. Leave the machine powered ON and idle overnight (no sleep, no restart).
4. Next day: all toggle-connected sessions show "disconnected", AND newly created sessions no longer auto-connect.
5. Run /remote-control in any ONE session -> the toggle resumes auto-connecting new sessions; previously-dropped sessions stay disconnected until each is /remote-control'd individually.

Note: %APPDATA%\Claude\bridge-state.json holds a single account-scoped bridge registration (key <bridgeId>:<accountUuid>, with enabled/userConsented + one remoteSessionId/localSessionId), consistent with a shared layer that goes stale wholesale.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.181 (embedded in Claude Desktop; cc_version=2.1.181.f17)

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

• Claude Code is the build EMBEDDED in the Claude Desktop app (entrypoint: claude-desktop), running as a child session with host-provided OAuth.
• Plan: Max 5x. Auth: claude.ai OAuth (no ANTHROPIC_API_KEY, primaryApiKey=false, no managed policy).
• /status is not surfaced in this Desktop build.
• Hypothesis: the account-scoped shared bridge registration and/or the short-lived RC credentials enter a failed state after a long idle and are not auto-refreshed; a manual /remote-control forces a fresh registration that repairs the shared layer for subsequently-created sessions, but already-dropped per-session transports are not rebuilt without their own /remote-control.