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

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

1. In ~/.claude/settings.json, set "remoteControlAtStartup": true.
2. Start a new session in the terminal CLI → Remote Control auto-enables ✅
3. Start a new session in the claude.app desktop app's "Code" tab → Remote Control is not auto-enabled ❌
4. /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:

1. Have the desktop Code tab honor remoteControlAtStartup from ~/.claude/settings.json for the embedded sessions it spawns, OR
2. Surface a "Enable Remote Control for all sessions" toggle in the desktop Code tab's UI (parity with the CLI's /config toggle), OR
3. 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.