[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

Status Open

Maintainer reply None cached

Activity 3 comments · opened Aug 18, 2026

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

Enable Remote Control by default in settings (preferences.ccRemoteControlDefaultEnabled: true).
Start a new session. It auto-enables correctly — [rcAutoEnable] verdict: enable=true source=explicit_pref, then Remote control enabled: https://claude.ai/code/session_....
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).
main.log shows [WarmLifecycle:session] Idle timeout reached, disconnecting <sessionId>.
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

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.
!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.

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.

View original on GitHub ↗

3 Comments

Choijiho1010 · 1 month ago

Same root cause, different trigger: /clear in Claude Desktop also drops Remote Control permanently

Confirming this on macOS with a trigger that doesn't involve the 900s idle timeout: /clear in a Claude Desktop Claude Code session tears down the CLI session handle, and auto-enable never re-arms — so Remote Control silently stays off for the rest of that session.

The contrast with the terminal CLI is the giveaway: in a terminal session, /clear resets the conversation inside the same process and the existing Remote Control connection survives. In Desktop, /clear drops the CLI session and re-attaches via the resume path, which skips the auto-enable evaluation described in this issue.

Environment

Claude Desktop 1.34493.1, Claude Code 2.1.226, macOS 26.5.2 (Apple silicon)
~/Library/Application Support/Claude/claude_desktop_config.json: "ccRemoteControlDefaultEnabled": true
~/.claude/settings.json: "remoteControlAtStartup": true

Repro

In Claude Desktop, open a Claude Code session (auto-enable is on) — Remote Control turns on and the session appears at claude.ai/code.
Run /clear.
Keep working in the same session.

Expected: the conversation resets on connected devices (per the docs) but Remote Control stays connected — as it does in the terminal CLI.
Actual: Remote Control is off and never re-enables. Nothing indicates this in the UI.

Log evidence (~/Library/Logs/Claude/main.log, ids truncated)

19:21:33 [info] Enabling remote control for session local_5372f240-…
19:21:34 [info] Remote control enabled: https://claude.ai/code/session_019Kxf…
19:21:40 [info] LocalSessions.clearSession: sessionId=local_5372f240-…
19:21:40 [info] Clearing session local_5372f240-…
19:21:40 [info] [CCD] clearStaleResumeHandle session=local_5372f240-… reason=clearSession dropping cliSessionId=61280e56-… unarchive

No Enabling remote control line follows for that session. Same pattern on earlier days: a reason=clearSession teardown is never followed by a re-enable — the only re-enables in the log are ones I triggered by hand.

One local session had accumulated 9 bridge sessions before it was deleted (Requested CCR delete of 9 Remote Control bridge session(s)), i.e. nine manual re-enables, each minting a new server session rather than resuming the previous one.

Suggested fix — the same one proposed in this issue: re-arm remoteControlAutoEligible (or preserve the RC binding) on any internal teardown/resume that the user did not initiate. reason=clearSession is internal cleanup, not a user disconnect, so it should be treated like the idle-teardown case.

Workaround for anyone hitting this: run /remote-control manually after every /clear. Don't toggle Remote Control off by hand — that sets remoteControlUserToggled and disqualifies the session from auto-enable for good.

oriegilboa · 1 month ago

Data point from Windows desktop 1.46388.4: a pause-skip guard now exists for RC-active sessions, but it is not applied to a session re-warmed by focus after an app restart — so that session is still paused 15 min later with RC off.

Environment: Claude desktop 1.46388.4 (Microsoft Store build), Windows 11 Pro 10.0.26200, "Enable remote control by default" on. Source: %LOCALAPPDATA%\Claude\logs\main.log, 2026-08-23 → 2026-09-08, covering builds 1.34493.1 → 1.37937.3 → 1.40609.0 → 1.44121.4 → 1.46388.1 → 1.46388.4 via auto-update.

1. The 900 s idle teardown is now skipped while Remote Control is active

[WarmLifecycle:session] Idle timeout reached, disconnecting <id>
[CCD] Skipping pause for session <id> - remote control is active (startup-policy bridge)
[WarmLifecycle:session] Session <id> has declined 8 consecutive idle pauses — its process is not being reaped
[WarmLifecycle:session] Starting idle timeout for <id>: 900s

Counts in this window: 3,733 Idle timeout reached (session), but only 18 real [CCD] Pausing session <id> (idle_timeout). Skip reasons: 402 × remote control is active (startup-policy bridge), 6 × remote control is active (explicit bridge), 15 × a turn may be in flight (CLI not provably idle).

Version boundary: on 1.34493.1–1.37937.3 (08-23 → 08-30 07:23) there are 8 real pauses and 0 declines. 1.40609.0 was installed 08-30 07:23:52; the first has declined … idle pauses is 08-30 11:04:02 and they continue from there. The explicit [CCD] Skipping pause … - <reason> line first appears on 1.44121.4 (09-03 08:15). So the "idle 15 min → RC off" case in the original report is handled for a session whose RC is active at the moment the timer fires.

2. `rcAutoEnable` now has three triggers — all driven by a desk-side action

[rcAutoEnable] verdict: enable=true source=explicit_pref trigger=first_turn    (21)
[rcAutoEnable] verdict: enable=true source=explicit_pref trigger=warm_send     (6)   ← follows LocalSessions.sendMessage
[rcAutoEnable] verdict: enable=true source=explicit_pref trigger=cold_resume   (5)

None of them fires on a warm-up that is not a send/resume.

3. Residual failure: a session re-warmed by focus after an app restart never gets RC back, so the guard does not apply and it is paused 15 min later

Same session, same build (1.46388.4):

# evening — user sends a message → auto-enable → protected through six timer fires
2026-09-06 19:30:04 [rcAutoEnable] verdict: enable=true source=explicit_pref trigger=warm_send
2026-09-06 19:30:04 Enabling remote control for session local_1aee6d0f-…
2026-09-06 20:12:10 [WarmLifecycle:session] Idle timeout reached, disconnecting local_1aee6d0f-…
2026-09-06 20:12:10 [CCD] Skipping pause for session local_1aee6d0f-… - remote control is active (explicit bridge)
   (same pair at 20:27, 20:42, 20:57, 21:12, 21:27)
2026-09-06 22:44:46 [updater] App is installed, enabling initial check and auto-updates   ← app restarted

# morning — user clicks the session in the sidebar → focus warm-up → NO auto-enable
2026-09-07 08:39:04 [CCD] Warming session local_1aee6d0f-…
2026-09-07 08:39:04 [CCD] LocalSessions.setFocusedSession: sessionId=local_1aee6d0f-…
2026-09-07 08:39:04 [CCD] Session local_1aee6d0f-… warmed successfully in 99ms
2026-09-07 08:39:07 [WarmLifecycle:session] Starting idle timeout for local_1aee6d0f-…: 900s
   (no [rcAutoEnable] line and no "Enabling remote control" for this session; the only one at 08:39:10 is for a different session)
2026-09-07 08:54:07 [WarmLifecycle:session] Idle timeout reached, disconnecting local_1aee6d0f-…
2026-09-07 08:54:07 [CCD] Pausing session local_1aee6d0f-… (idle_timeout)
2026-09-07 08:54:09 Session local_1aee6d0f-… query iterator completed

Result: the session stays in the sidebar, the phone shows it offline, and from the phone there is nothing to send to. This account's session list currently shows 31 sessions as "Remote Control · offline"; the log window has 13 app starts. The three real pauses in the first three hours of 1.40609.0 (08-30 08:04 / 08:42 / 10:18) and the three right after the 09-03 restart (07:52 / 08:04 / 08:04) fit the same pattern.

Suggested fix

Evaluate rcAutoEnable (or restore the persisted RC binding — cf. #86084) on every warm-up path, including [CCD] Warming session after a restart and preview warm-ups, not only on first_turn / warm_send / cold_resume. Then the existing Skipping pause … remote control is active guard covers the rest.

Workaround that works in-session (for anyone hitting this now)

A no-op CronCreate tick every 12 min (3,15,27,39,51 * * * *, prompt "do nothing, reply one line") completes a turn and re-arms the 900 s timer so it never fires; the desktop logs [CCD] Session <id> cron <job> confirmed (active: 1). Limits: it dies with the app process (so it does not cover the restart case above) and session crons expire after 7 days. A Windows Scheduled Task running claude --resume <id> is not a workaround — it is a separate process, does not touch the desktop's WarmLifecycle, and per the docs gets Remote Control not started here and leaves RC off.

DanielWiebelhaus · 27 days ago

Confirming that the residual failure described in the comment above — after an app restart the session does not get Remote Control back, so the idle-pause guard no longer applies and the session is paused 15 minutes later — is still present on the Microsoft Store / MSIX build 2.110.1 (Claude Code 2.1.271, Windows 11 Pro 25H2, build 26200.9457). Here the restart was the app's own automatic update relaunch in three of four cases.

Latest case, 2026-09-17: Skipping pause for session … - remote control is active (explicit bridge) at 06:02 → update relaunch at 06:05 (Version changed since last launch: 2.110.0 → 2.110.1, [stealth-relaunch] Detected via marker file) → [CCD] Pausing session … (idle_timeout) at 06:20 → no Remote Control until [rcAutoEnable] verdict: enable=true source=user_intent trigger=warm_send at 08:08. No rcAutoEnable verdict is logged after the relaunch itself, and the session files show "remoteControlAutoEligible": false.

Remote Control was not restored in any of the 4 cases in four days where it was demonstrably on right before the app quit. Full log evidence: https://github.com/anthropics/claude-code/issues/94049#issuecomment-5710169631

[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

Summary

Steps to reproduce

Evidence

Mechanism (from app.asar)

Two related gotchas found while diagnosing

Suggested fix

Related

3 Comments

1. The 900 s idle teardown is now skipped while Remote Control is active

2. rcAutoEnable now has three triggers — all driven by a desk-side action

3. Residual failure: a session re-warmed by focus after an app restart never gets RC back, so the guard does not apply and it is paused 15 min later

Suggested fix

Workaround that works in-session (for anyone hitting this now)

Related Claude Code issues

Browse by topic

Mechanism (from `app.asar`)

2. `rcAutoEnable` now has three triggers — all driven by a desk-side action