[BUG] Desktop: Remote Control auto-enable only fires on a session's first turn, so the 900s idle teardown silently turns it off for good

Claude desktop app version: 1.32352.1.0 (Windows Store build)
Platform: Windows 11 Pro 26200

Summary

In the desktop app, "Remote Control on by default" (ccRemoteControlDefaultEnabled) is evaluated only on a session's first turn. Separately, WarmLifecycle:session tears a session down after 900s idle, and that teardown clears the remote-control state. Every turn after that is a resume, so auto-enable never runs again and Remote Control stays off for the life of that session.

The practical result is that Remote Control is unavailable for its primary use case: you step away, come back later wanting to drive a session from your phone, and it has silently turned itself off — and you have to be back at the desk to turn it on again. Sessions you are actively using keep it fine; only parked ones lose it, which is exactly backwards.

Steps to reproduce

1. Enable Remote Control by default in settings (preferences.ccRemoteControlDefaultEnabled: true).
2. Start a new session. It auto-enables correctly — [rcAutoEnable] verdict: enable=true source=explicit_pref, then Remote control enabled: https://claude.ai/code/session_....
3. Leave that session alone for 15+ minutes (trivially easy with several sessions open — any session you are not currently typing in is idle by definition).
4. main.log shows [WarmLifecycle:session] Idle timeout reached, disconnecting <sessionId>.
5. Return to the session and send a message. No [rcAutoEnable] verdict is logged, no re-enable happens. Remote Control is off and must be toggled by hand.

Evidence

From %APPDATA%/Claude/logs/main.log, across 23h of continuous app uptime on one machine:

• 38 [WarmLifecycle:session] Idle timeout reached, disconnecting events
• 5 [rcAutoEnable] verdict: lines total — each one within ~3s of a session's createdAt, i.e. first turn only
• 0 re-evaluations after any idle teardown or any resume

Concrete case from that log:

11:59:44 [rcAutoEnable] verdict: enable=true source=explicit_pref
11:59:47 Remote control enabled: https://claude.ai/code/session_01BYdi...
11:59:47 [remote-control] bridge_state: connected
14:40:51 [WarmLifecycle:session] Idle timeout reached, disconnecting local_228316ae-...
         (no further rcAutoEnable / remote-control lines for this session)

Sessions created before the current app process started have never been auto-enabled at all during that process, because every turn in them is a resume.

Mechanism (from app.asar)

Auto-eligibility is set only on the non-resume path:

s && (o.remoteControlAutoEligible = !0), this.maybeAutoEnableRemoteControl(...)

where s is the same not-a-resume flag feeding { isResume: !!d.resume || !s }. The policy gate requires it:

shouldEvaluateRemoteControlPolicy(e) {
  return !!e.remoteControlAutoEligible
      && !e.remoteControlEnabled
      && !e.remoteControlUserToggled
      && !e.remoteControlAutoInFlight
}

The idle teardown reaches the dead-CLI cleanup (settleBackgroundTasksForDeadCli), which calls:

clearRemoteControlState(e) {
  e.remoteControlEnabled = !1,
  e.remoteControlAutoEnabled = void 0,
  e.remoteControlAutoSource = void 0,
  e.remoteControlConnecting = void 0,
  e.bridgeSessionId = ...
}

So the flag is cleared, and nothing re-arms it. The session idle timeout is hardcoded (idleTimeoutMs: () => 9e5) with no user-facing preference.

Two related gotchas found while diagnosing

1. bridgeSessionIds in claude-code-sessions/**/local_*.json persists after the bridge is gone, so the on-disk record shows a bridge id for sessions whose Remote Control is off. It is a history of bridges created, not live state — easy to misread when debugging.
2. !e.remoteControlUserToggled in the gate means that manually toggling Remote Control off once permanently disqualifies that session from ever auto-enabling again, even on an otherwise-eligible first turn.

Suggested fix

Re-evaluate the auto-enable policy when a session is re-warmed after an idle teardown, not only on the first turn — or leave the remote-control binding intact across a warm-lifecycle teardown, since the teardown is an internal resource optimization rather than a user-initiated disconnect. Either would restore the "walk away, pick it up on your phone" case.

Related

Similar symptom, different layer: #87213 covers the CLI replaying a dead Remote Control binding on --resume. This report is the desktop app, where the cause is the first-turn-only auto-enable gate combined with the 900s warm-lifecycle teardown.