Persistent always-on Remote Control option for desktop app

[v0ltfault]

Summary

The CLI supports remoteControlAtStartup: true in ~/.claude.json to auto-enable Remote Control for every session. The desktop app (v1.2773.0.0 with claude-code 2.1.92 bundled) ignores this setting — it uses a separate per-session remoteControlEnabled runtime state that defaults to false and must be manually toggled for each session.

Use case

I use Claude Code primarily from my phone via the Claude mobile app's Remote Control feature. Having to walk to my PC and manually enable Remote Control for each new desktop session defeats the purpose of mobile access.

Evidence from code

• ~/.claude.json has remoteControlAtStartup (read by Fd() in claude-code backend 2.1.92)
• Desktop app (1.2773.0.0) has separate remoteControlEnabled runtime state: e.remoteControlEnabled=!1 (defaults false, must be toggled per session)
• The two are not wired together — setting the CLI flag has no effect on desktop app behavior

Requested fix

Have the desktop app honor remoteControlAtStartup from ~/.claude.json, or add an equivalent persistent toggle in the desktop app UI (currently /config is CLI-only).

Environment

• Windows 11 25H2
• Claude Code Desktop 1.2773.0.0 (claude-code 2.1.92 bundled)

[github-actions]

Found 3 possible duplicate issues:

1. Desktop app sessions should be accessible via remote control #36795
2. Enable Remote Control for Claude Code sessions in Claude Desktop App #29006
3. Add remoteControlEnabled setting to auto-start /remote-control on session start #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

[roccolangeweg]

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)

[alexanderblackh]

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.

[leithl]

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