[BUG] Remote Control: continuing a Mac-created session from iOS intermittently fails to connect — "active worker" contention (close code 4090) + 15-min warm idle timeout

Environment

• Host: Mac mini, macOS (Darwin 25.5.0), Claude Desktop + Claude Code up to date
• Remote Control daemon healthy: single com.anthropic.claude-remote-control --name "Mac mini", LastExitStatus = 0, token valid (Max), no duplicate daemons, no 401s
• Client: Claude mobile app (iOS), opening/continuing an existing session that was created on the Mac

Description

Continuing a session created on the Mac from the iOS app intermittently shows the session as unreachable / offline ("won't connect"). It is not every time — it depends on timing — which made it hard to pin down. Digging into the desktop app log (~/Library/Logs/Claude/main.log) surfaces two concrete mechanisms that together explain the intermittent failure.

Mechanism 1 — 15-minute warm idle timeout drops the relay connection

Warm sessions are disconnected from the relay after 900s idle, on a repeating cycle:

[WarmLifecycle:session] Starting idle timeout for local_<id>: 900s
[WarmLifecycle:session] Idle timeout reached, disconnecting local_<id>

So any session left idle for >15 min is no longer connected to the relay and must be re-warmed before the phone can reach it. A full re-warm ([WarmLifecycle:session] Warming up session) fires far less often (tens of times) than the idle-disconnect cycle (thousands of times) in the same log window, so the disconnect is frequently not followed by a prompt re-registration.

Mechanism 2 — "active worker" contention on the relay (WebSocket close code 4090)

The relay allows only one connection to be the active worker for a given session. When a second connection claims it (e.g. iOS opening a session already warm on the desktop, or the device bridge rotating), the previous connection is dropped:

[remote-control] bridge_state: failed — Transport closed: this connection is no longer the active worker for the session (code 4090)

bridge_state distribution over one day on this machine: connected 178, ready 102, failed 52, reconnecting 8 — i.e. ~1 in 6 bridge state transitions ends in a failed/4090. If the handoff races (the old worker is evicted but the new one doesn't cleanly take over), the session ends up with no active worker connected, and iOS shows it as unreachable. Because it depends on handoff timing, the failure is intermittent — matching the reported "sometimes won't connect."

Steps to reproduce

1. Create/open a session on the Mac (desktop app), leave it idle for >15 minutes.
2. From the iOS app, open that same session to continue it.
3. Intermittently, the session fails to connect / shows offline. Retrying or creating a brand-new session (which re-registers cleanly) works.

Expected behavior

• On iOS opening a session, deterministically re-warm and re-register the desktop worker before declaring the session reachable, rather than racing the eviction.
• Avoid evicting the existing worker (code 4090) until the new worker has fully taken over; if the takeover fails, fall back to the previous worker instead of leaving the session with no active worker.
• Consider a longer/adaptive warm idle timeout, or transparent re-warm on demand, so idle sessions remain reachable from mobile.

Related issues

• #76811 — Remote Control environment lifecycle issues (closest)

Workaround

When an idle Mac-created session won't open from iOS, create a new session from the phone (it re-registers cleanly) rather than retrying the stale one; or hand off within 15 minutes of activity.