Persistent always-on Remote Control option for desktop app

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/36795
2. https://github.com/anthropics/claude-code/issues/29006
3. https://github.com/anthropics/claude-code/issues/37589

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I'd like this as well, becoming more and more an user that only steers via mobile and would love to have desktop sessions show up automatically. (Or even better, allow me on mobile to create a new session on the desktop app similar to 'claude remote-control' (but not fixed to a path)

Another +1 for this. Tailscale plus VNC software provides a decent workaround for now, but if we could just have it on by default in both CLI and Desktop, that'd be a game changer with my Claude Max.

+1 — same gap on macOS (Claude.app 1.5354.0, claude-code 2.1.121 bundled). Reproduced today: remoteControlAtStartup: true in ~/.claude/settings.json starts the bridge daemon at app launch (verified via [buddy] bridge started in ~/Library/Logs/Claude/main.log) and restores remote control on previously-controlled sessions, but never auto-enables it on freshly-created conversation sessions. Detailed log excerpts in #54527.

So this isn't Windows-specific — it's a desktop-app-wide gap on both platforms. Worth removing the platform:windows label.

Doc clarity note while a fix is being considered

A few schema descriptions in the Claude Code settings schema actively contributed to me misdiagnosing this — flagging in case the fix lands alongside doc edits:

• remoteControlAtStartup — current: "Start Remote Control bridge automatically each session". The "each session" wording reads as "every conversation session" but the real scope is "at app launch." Suggested rewrite: "Start the Remote Control bridge daemon at app launch. Per-conversation enablement is still manual via /remote-control (or restored from cloud state for previously-controlled sessions)."

• daemonColdStart — current: "When no background service is running: 'transient' spawns one for this login session; 'ask' offers to install it persistently". Doesn't name which background service, and in my testing on the desktop app the setting had no observable effect (the bridge was already starting via remoteControlAtStartup's code path). Suggested: name the service explicitly, and clarify whether this setting is honored by the desktop app or only by the standalone CLI.

• autoUploadSessions vs remoteControlAtStartup — the relationship is non-obvious. A one-line cross-reference ("for read+write control instead of read-only mirroring, see remoteControlAtStartup") would help.

Restating the FR for completeness

A setting that auto-enables remote control on every new conversation session (not just bridge startup, not just cloud-state restoration). Either:

1. Make remoteControlAtStartup: true also auto-enable per-session (matches what the name + current description already imply), OR
2. Add a separate remoteControlPerSessionDefault: true and clarify remoteControlAtStartup is bridge-only.

Option 1 aligns with user intuition; option 2 is more explicit if you want to keep the current bridge-only behavior addressable.

+1

Confirming on Claude desktop 1.10628.0.0 (Windows, MSIX/Store install).

"Settings → Claude Code → Enable remote control by default" is ON.
After restarting the app (or rebooting the machine), every project shows
"Turn on Remote Control" — i.e. remote control is OFF and must be enabled
manually per project. The default toggle does not apply on startup.

Expected: with the toggle ON, remote control should auto-enable for
projects when the app launches, so a 24/7 setup reconnects without
manual clicks after reboot.

Use case: machine runs unattended (auto-login + auto-restart). Having to
manually re-enable remote control per project after every reboot defeats
the unattended setup.

Strong +1. I would frame this even more broadly: this should be a persistent Claude Desktop product setting, not just a config-file behavior.

OpenAI Codex has made remote/session control feel like a normal product capability rather than a daemon users have to think about. Claude Code should match that bar:

• one global Desktop setting to allow remote control
• no manual daemon/server startup for Desktop users
• no per-session toggle ceremony once the user has opted in
• mobile should list active Desktop/Claude Code sessions and allow new session creation/resume/control

The current model makes Remote Control feel like an implementation detail. For users comparing Claude Code to Codex, this is now a visible product gap.

+1, very much needed to be able to keep on working after switching sessions/remote restarting.

It hurts a lot that this is still a bug

Reproduced on a newer Windows build, with a clean pre/post-reboot control and direct evidence of the skipped Desktop lifecycle path.

Environment

• Windows 11
• Claude Desktop 1.24012.9.0 (Microsoft Store package)
• Desktop-bundled Claude Code 2.1.219
• Standalone Claude Code 2.1.220
• First-party claude.ai Max authentication
• C:\Users\<user>\.claude\settings.json: remoteControlAtStartup: true

Observed control case: new session

A genuinely new Desktop Code session evaluated the preference and connected normally:

[rcAutoEnable] verdict: enable=true source=explicit_pref
Enabling remote control for session [redacted]
[remote-control] bridge_state: ready
Remote control enabled: https://claude.ai/code/[redacted]
[remote-control] bridge_state: connected

Multiple sessions were then visible as Connected in the Claude mobile app.

Observed failure: restored session after reboot

After reboot, Claude Desktop:

1. loaded the persisted session inventory;
2. warmed an existing Desktop Code session successfully;
3. resumed the same local/CLI conversation identity; and
4. retained the session's historical bridgeSessionIds in its persisted JSON.

But the restored session produced no [rcAutoEnable] verdict, Enabling remote control, bridge ready, or bridge connected event. All previously connected sessions appeared disconnected on mobile. Typing /remote-control manually in each restored Desktop session immediately created a working bridge.

The preference, first-party authentication, and relevant environment-variable checks all remained valid after reboot, so this is not a configuration or whole-host eligibility failure.

Installed Desktop control flow

Read-only inspection of the installed Desktop bundle shows the effective flow below:

enqueueInitialMessage(..., isFirstTurn, ...):
    ...
    if isFirstTurn:
        maybeAutoEnableRemoteControl(session, settings)

maybeAutoEnableRemoteControl(...):
    resolve remoteControlAtStartup
    log [rcAutoEnable] verdict
    if enabled:
        handleRemoteControlCommand(auto=true)

The resume/warm path restores the existing CLI session but has no corresponding Remote Control auto-enable call. This exactly matches the logs: a new/first-turn session evaluates the preference; a restored session does not.

Requested fix

When a Desktop query process starts or a persisted session is warmed after process loss, evaluate the effective Remote Control startup preference. If enabled and no live bridge exists, invoke the existing idempotent bridge handler regardless of isFirstTurn.

Suggested regression coverage:

1. New session + preference on → exactly one live bridge.
2. Existing session after Desktop restart → reconnects automatically.
3. Existing session after Windows reboot → reconnects automatically.
4. Preference off → no bridge.
5. Bridge already live → no duplicate.
6. Multiple restored sessions → each independently reachable without manual slash commands.

This reproduction is narrower than #76954: the local Desktop sessions restore and remain usable here; the defect is specifically that their live Remote Control registrations are not recreated.

Account, organization, local-session, and Remote Control session identifiers are intentionally redacted. Full timestamps can be provided privately if maintainers need them.

Following. Interested in this as well!

Confirming this on Windows 11 25H2 with claude-code 2.1.209.

Adding one data point that may help narrow it down: I have all three known toggles set to true simultaneously, and the behavior still reproduces on every desktop app launch. That is remoteControlAtStartup: true in both ~/.claude.json and ~/.claude/settings.json, plus ccRemoteControlDefaultEnabled: true in the Claude desktop config. So this is not one setting shadowing another, and there is no config combination that works today.

One reporting note: the desktop key is nested inside the preferences object rather than at the top level of claude_desktop_config.json. Checking the top level returns nothing, which makes it easy to report as unset when it is actually set.

The split described in the original report matches exactly what I see. The CLI path honors the setting correctly: sessions started or resumed with claude --resume in a terminal register for remote control with no intervention. Only sessions opened in the desktop app come back with remote control off, and each one needs a manual toggle.

Given that, this reads more like a defect than an enhancement: the CLI honors a documented setting and the desktop app silently ignores the same setting, with no user-visible indication that it was disregarded.

This also looks like the same underlying cause as #68250, which reports the desktop key specifically being ignored. Both would be resolved by wiring the persisted setting to the per-session remoteControlEnabled runtime state rather than defaulting it to false.

Use case matches the original report: the mobile app is my primary way of picking up a running session, so having to walk to the machine to enable remote control removes most of the value.

Feature request: make Remote Control persist across restarts in the desktop app.

I keep several long-running sessions with Remote Control turned on so I can pick
them up from my phone when I'm away. The problem: every time my PC restarts, or
if the desktop app closes and reopens, all those sessions come back with Remote
Control OFF. I have to open each session and click the computer icon at the top
to turn it back on, one by one.

Please add a way to keep Remote Control ON for chosen sessions so it
re-activates automatically when the app reopens — ideally a per-session
"always keep remote control on" setting, or a global setting that actually
re-arms existing/resumed sessions on launch. Right now the only auto-on-boot
option is the CLI --remote-control flag, which can't run while the same session
is open in the desktop app.

This was working before and has stopped working. This is a major breakage in a key feature, I have to trigger /remote-control every single time and its problematic. Please fix

Another data point confirming there is no working config combination.

Environment:

• Windows 11 Home 26200
• Claude Code CLI 2.1.220
• Claude Desktop app, Code tab, several long-running local sessions

Config, all set and verified on disk before testing:

• ~/.claude/settings.json -> "remoteControlAtStartup": true (in place since early July)
• %APPDATA%/Claude/claude_desktop_config.json -> preferences.ccRemoteControlDefaultEnabled: true
• No managed-settings file present
• disableRemoteControl not set anywhere
• None of DISABLE_TELEMETRY, DO_NOT_TRACK, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_GROWTHBOOK, ANTHROPIC_BASE_URL, ANTHROPIC_API_KEY set in the environment or in the settings env block

Behavior: every desktop app restart brings every restored session back with Remote Control OFF. Each one has to be re-enabled by hand with /rc or the computer icon.

This matches the reasoning in the docs: Remote Control is hosted by the claude process, so an app restart kills the owner and a restored session is a resume rather than a start, while remoteControlAtStartup only auto-connects on session start. That makes the two existing toggles structurally unable to cover the restore path, which is why no combination of them helps.

What would solve it from a user standpoint: have restore re-establish Remote Control for any session that had it on when the app closed, or a per-session "keep Remote Control on" flag that survives restart.