Desktop Code tab doesn't honor `remoteControlAtStartup` from ~/.claude/settings.json

Status Closed — not planned

Reported on v2.1.111

Maintainer reply None cached

Activity 7 comments · opened Apr 17, 2026 · closed Jun 2, 2026

Summary

The remoteControlAtStartup: true setting in ~/.claude/settings.json auto-enables Remote Control for every new session in the terminal CLI, but does not take effect in the claude.app desktop app's Code tab. Each new Code session starts with Remote Control disabled; /config isn't available in that context to toggle it either.

Environment

macOS 15.x (Darwin 25.5.0)
Claude desktop app (latest)
Embedded Claude Code at ~/Library/Application Support/Claude/claude-code/2.1.111/claude.app/Contents/MacOS/claude
Terminal claude CLI installed separately

Repro

In ~/.claude/settings.json, set "remoteControlAtStartup": true.
Start a new session in the terminal CLI → Remote Control auto-enables ✅
Start a new session in the claude.app desktop app's "Code" tab → Remote Control is not auto-enabled ❌
/config is unavailable inside the desktop Code tab, so there's no UI to toggle the equivalent preference.

What I found while investigating

The desktop's embedded Claude Code install dir has no separate settings.json (only the .app bundle and a .verified marker), which suggests the embedded CLI should already read ~/.claude/settings.json.
The desktop app's own ~/Library/Application Support/Claude/config.json stores OAuth/theme/migration state only — no remoteControlAtStartup analogue.
So either (a) the embedded CLI reads the file but remoteControlAtStartup is a CLI-only startup behavior, or (b) the desktop host app wraps the session and manages Remote Control activation separately from the embedded CLI's startup flag.

Request

One of:

Have the desktop Code tab honor remoteControlAtStartup from ~/.claude/settings.json for the embedded sessions it spawns, OR
Surface a "Enable Remote Control for all sessions" toggle in the desktop Code tab's UI (parity with the CLI's /config toggle), OR
Make /config available inside the desktop Code tab.

Any of these would close the gap. Option 1 is the least-surprise behavior given the shared-settings-file model.

Why this matters

The terminal CLI's auto-start behavior is useful precisely because it removes a per-session step. Desktop Code sessions need the same convenience to be first-class — right now the desktop feels like a downgrade from the CLI for users who rely on Remote Control.

View original on GitHub ↗

6 Comments

jasonpiepmeier · 4 months ago

+1 — hitting the same friction on the Claude Desktop app for Mac. Every new session in the Code tab requires manually typing /remote-control. A remoteControlEnabled: true setting (per #37589) would fix this across CLI and Desktop.

natekettles · 4 months ago

+ 1 (_more if I could!_).
Claude clearly wants us to use the Desktop app, so either honouring the flag or exposing a toggle in the Desktop app itself would go a long way to making it a first-class experience.

jaredingold · 3 months ago

having the same issue... as a temp workaround I'm starting multiple sessions before i leave my workstation, setting each to remote-control, then using dispatch to run them... would be really nice to allow either dispatch to run remote-control or let the settings (remote control = true) work in the desktop app

github-actions[bot] · 2 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

oliverames · 2 months ago

Still hitting this in June 2026 — the desktop Code tab continues to ignore remoteControlAtStartup, requiring a manual /remote-control at the start of every session.

I filed a related follow-up at #70602 that documents two additional failure modes that make the friction worse in practice:

The in-app "Enable for all sessions" toggle (added after this issue was closed) also doesn't reliably persist remote control across restarts — so the UI-level workaround for the missing remoteControlAtStartup support doesn't work either.
Model quota/rate-limit pauses kill the bridge process, so even a session where /remote-control was manually activated requires re-running it after every quota stop.

The net effect is that Remote Control requires repeated manual intervention throughout a normal working day. Reopening or at least linking to #70602 for tracking would be helpful given the continued impact.

oliverames · 2 months ago

Correction to my comment above: Claude.app does now have an "Enable Remote Control for all sessions" toggle in its UI — so the original request here was addressed.

The remaining gap (tracked in #70602) is that the toggle itself doesn't reliably work: the session still requires a manual /remote-control after app restarts and after model quota-limit pauses, despite the preference being on. So the feature landed but has a persistence bug on top of it.

Showing cached comments. Read the full discussion on GitHub ↗