Preflight Checklist
What's Wrong?
Environment
Claude Desktop 1.24012.9 (x64, MSIX), Windows 11 Pro 26200
Bundled Claude Code 2.1.219
Auto-connect enabled via Settings → Claude Code (resolves as source=explicit_pref)
Summary
With "enable Remote Control by default" turned on, newly created Desktop sessions bridge correctly and appear as online in the Claude mobile app. Sessions that are resumed never bridge, and show as disconnected on mobile indefinitely. No setting corrects this, because the preference is never read on the resume path.
Impact
Any long-running thread becomes permanently unreachable from mobile after the process stops or the app restarts. Users must run /remote-control manually in every resumed thread, defeating the auto-connect preference.
What Should Happen?
Any long-running thread becomes reachable from mobile after the process stops or the app restarts.
Error Messages/Logs
Steps to Reproduce
Enable Remote Control by default in Desktop settings.
Start a new session — it bridges, and shows online in the mobile app. ✅
Let the session stop (15-minute WarmLifecycle idle timeout, or restart the app).
Send it a message to resume it.
Session resumes and runs a normal turn — but no bridge is created. ❌
Expected: the auto-connect preference is honored on resume, and the session reappears as online on mobile.
Actual: Remote Control is never attempted. No [rcAutoEnable] verdict is logged at all.
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
No response
Claude Code Version
1.24012.9
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
Root cause
In app.asar, maybeAutoEnableRemoteControl has exactly two occurrences — one definition and one call site. The call site is the final statement of enqueueInitialMessage:
const { sessionId:r, cliSessionId:t, options:s, currentSession:i, isFirstTurn:n, … } = e;
…
this.replayPendingVisibility(r),
n && this.maybeAutoEnableRemoteControl(i, f) // n === isFirstTurn
Because n is isFirstTurn, the auto-enable path is unreachable for any resumed session, so the eligibility resolver (getAppPreference('ccRemoteControlDefaultEnabled') → explicit_pref) is never consulted.
The same function contains the complementary branch, which makes the two mutually exclusive:
if (!n && (i.cliSessionId ?? i.unarchivedCliSessionId)) { /* load prior transcript */ }
Evidence
A resume in which the transcript-load branch fires and auto-enable does not, within one invocation:
Resuming session local_5094… in
Loaded 1395 transcript messages for session local_5094… ← !isFirstTurn branch
Mapping internal session local_5094… to CLI session cb41…
[CCD start-timing] … init=17924ms first_assistant=14409ms
[CCD CycleHealth] healthy cycle for local_5094… (38s, hadFirstResponse=true)
No [rcAutoEnable] verdict, Enabling remote control, or bridge_state line appears anywhere in that window, and the session's bridgeSessionIds array is unchanged. Since the verdict line is logged unconditionally before the enable branch, its absence shows the function was never entered — not that it ran and declined.
By contrast, every [rcAutoEnable] verdict: enable=true source=explicit_pref in the log corresponds to a session creation, and each is followed within ~4s by bridge_state: connected.
Ruled out
Auth / subscription / org policy — resolver returns enable=true
ANTHROPIC_BASE_URL — set to canonical https://api.anthropic.com; no ANTHROPIC_API_KEY, CLAUDE_CODE_OAUTH_TOKEN, Bedrock or Vertex variables
disableRemoteControl / managed settings — absent
CLI-side remoteControlAtStartup: true — no effect, since Desktop drives Remote Control for sessions it hosts
Main-process event-loop stalling — present at one point but independent; the reproduction above ran with an 18s init
Suggested fix
Invoke the auto-enable check on the resume path as well as first turn — either by removing the isFirstTurn gate at that call site, or by calling maybeAutoEnableRemoteControl from the session-resume path once query is available. Note that handleRemoteControlCommand suppresses its no_active_session warning when {auto:true}, so a resume-path call made before query exists would fail silently; it should be sequenced after query setup.
Workaround
Run /remote-control in each resumed session, or use the UI control backed by LocalSessions.toggleRemoteControl(sessionId, enable).
Preflight Checklist
What's Wrong?
Environment
Claude Desktop 1.24012.9 (x64, MSIX), Windows 11 Pro 26200
Bundled Claude Code 2.1.219
Auto-connect enabled via Settings → Claude Code (resolves as source=explicit_pref)
Summary
With "enable Remote Control by default" turned on, newly created Desktop sessions bridge correctly and appear as online in the Claude mobile app. Sessions that are resumed never bridge, and show as disconnected on mobile indefinitely. No setting corrects this, because the preference is never read on the resume path.
Impact
Any long-running thread becomes permanently unreachable from mobile after the process stops or the app restarts. Users must run /remote-control manually in every resumed thread, defeating the auto-connect preference.
What Should Happen?
Any long-running thread becomes reachable from mobile after the process stops or the app restarts.
Error Messages/Logs
Steps to Reproduce
Enable Remote Control by default in Desktop settings.
Start a new session — it bridges, and shows online in the mobile app. ✅
Let the session stop (15-minute WarmLifecycle idle timeout, or restart the app).
Send it a message to resume it.
Session resumes and runs a normal turn — but no bridge is created. ❌
Expected: the auto-connect preference is honored on resume, and the session reappears as online on mobile.
Actual: Remote Control is never attempted. No [rcAutoEnable] verdict is logged at all.
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
No response
Claude Code Version
1.24012.9
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
Root cause
In app.asar, maybeAutoEnableRemoteControl has exactly two occurrences — one definition and one call site. The call site is the final statement of enqueueInitialMessage:
const { sessionId:r, cliSessionId:t, options:s, currentSession:i, isFirstTurn:n, … } = e;
…
this.replayPendingVisibility(r),
n && this.maybeAutoEnableRemoteControl(i, f) // n === isFirstTurn
Because n is isFirstTurn, the auto-enable path is unreachable for any resumed session, so the eligibility resolver (getAppPreference('ccRemoteControlDefaultEnabled') → explicit_pref) is never consulted.
The same function contains the complementary branch, which makes the two mutually exclusive:
if (!n && (i.cliSessionId ?? i.unarchivedCliSessionId)) { /* load prior transcript */ }
Evidence
A resume in which the transcript-load branch fires and auto-enable does not, within one invocation:
Resuming session local_5094… in
Loaded 1395 transcript messages for session local_5094… ← !isFirstTurn branch
Mapping internal session local_5094… to CLI session cb41…
[CCD start-timing] … init=17924ms first_assistant=14409ms
[CCD CycleHealth] healthy cycle for local_5094… (38s, hadFirstResponse=true)
No [rcAutoEnable] verdict, Enabling remote control, or bridge_state line appears anywhere in that window, and the session's bridgeSessionIds array is unchanged. Since the verdict line is logged unconditionally before the enable branch, its absence shows the function was never entered — not that it ran and declined.
By contrast, every [rcAutoEnable] verdict: enable=true source=explicit_pref in the log corresponds to a session creation, and each is followed within ~4s by bridge_state: connected.
Ruled out
Auth / subscription / org policy — resolver returns enable=true
ANTHROPIC_BASE_URL — set to canonical https://api.anthropic.com; no ANTHROPIC_API_KEY, CLAUDE_CODE_OAUTH_TOKEN, Bedrock or Vertex variables
disableRemoteControl / managed settings — absent
CLI-side remoteControlAtStartup: true — no effect, since Desktop drives Remote Control for sessions it hosts
Main-process event-loop stalling — present at one point but independent; the reproduction above ran with an 18s init
Suggested fix
Invoke the auto-enable check on the resume path as well as first turn — either by removing the isFirstTurn gate at that call site, or by calling maybeAutoEnableRemoteControl from the session-resume path once query is available. Note that handleRemoteControlCommand suppresses its no_active_session warning when {auto:true}, so a resume-path call made before query exists would fail silently; it should be sequenced after query setup.
Workaround
Run /remote-control in each resumed session, or use the UI control backed by LocalSessions.toggleRemoteControl(sessionId, enable).