Remote Control: ccRemoteControlDefaultEnabled + remoteControlAtStartup collide — desktop session disables itself on first message (trigger for #77915)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Remote Control has two independent auto-enable settings that both apply to a desktop
session, with no coordination between them:

• ccRemoteControlDefaultEnabled — desktop app preference, Settings → Claude Code →

"Enable remote control by default"

• remoteControlAtStartup — CLI setting in ~/.claude/settings.json (also readable

from ~/.claude.json config), surfaced in the terminal /config panel as
"Remote Control for all sessions"

With both set to true, a new desktop session connects normally, and then the
first message you send triggers a spurious disable of Remote Control on that
session — which immediately hits the unguarded session_url read tracked in #77915
and leaves the toggle stuck ON (#78336).

This appears to be the missing trigger in those two issues: every report there
describes a manual toggle-off. Here nothing is toggled by the user at all — the
session disables itself on the first message, purely from configuration.

Two problems, one root:

1. The two settings both act as owners of Remote Control for the same session. The

desktop app resolves its own preference first and only falls through to the
settings layers when the preference is unset ([rcAutoEnable] verdict: enable=true
source=explicit_pref vs source=explicit_settings), so when both are set, two
paths race for one session.

1. There is no way to scope remoteControlAtStartup to terminal sessions. The

desktop app and the terminal read the same ~/.claude/settings.json, and the
binary exposes no env-var override for it (the CLAUDE_CODE_* surface has only
remote-session internals — CLAUDE_CODE_REMOTE_SESSION_ID,
CLAUDE_CODE_REMOTE_ENVIRONMENT_TYPE, etc. — nothing gating startup auto-connect).
So a user who wants terminal sessions to auto-connect cannot express that without
also breaking every desktop session. The /config label "Remote Control for all
sessions" actively suggests this is the right knob to set.

What Should Happen?

Setting both should be a no-op, not a self-disable: whichever path connects first
should own the session, and the second should see it already connected and stand
down. Failing that, remoteControlAtStartup should be scoped (or renamed) so its
blast radius matches its label, and the desktop app should ignore it when its own
preference is what drove the connection.

Error Messages/Logs

# ~/Library/Logs/Claude/main.log — new desktop session, both settings true.
# Nothing was toggled by hand at any point.

12:39:29 [info]  [rcAutoEnable] verdict: enable=true source=explicit_pref
12:39:29 [info]  Enabling remote control for session local_a01809db-…
12:39:31 [info]  [remote-control] bridge_state: ready
12:39:31 [info]  Remote control enabled: https://claude.ai/code/session_01XdFNTR…
12:39:31 [info]  [remote-control] bridge_state: connected
12:39:33 [info]  LocalSessions.sendMessage: sessionId=local_a01809db-…, messageLength=15
12:39:33 [info]  Disabling remote control for session local_a01809db-…   <-- unprompted
12:39:33 [error] Failed to toggle remote control for local_a01809db-…: Cannot read
                 properties of undefined (reading 'session_url')

For contrast, the same app with only ccRemoteControlDefaultEnabled set connects and
stays connected — no disable, no error:

12:25:07 [info]  [rcAutoEnable] verdict: enable=true source=explicit_pref
12:25:07 [info]  Enabling remote control for session local_e94a5ae3-…
12:25:09 [info]  Remote control enabled: https://claude.ai/code/session_016gpbrf…
12:25:09 [info]  [remote-control] bridge_state: connected

Steps to Reproduce

1. In the desktop app, enable Settings → Claude Code → "Enable remote control by

default".

1. Add "remoteControlAtStartup": true to ~/.claude/settings.json.
2. Start a new session in the desktop app and send any message.
3. Observe in the chat: `Remote Control failed to disconnect: Cannot read properties

of undefined (reading 'session_url')`, ~2 seconds after the session connected
successfully.

Removing remoteControlAtStartup from settings.json resolves it; desktop sessions
then connect and stay connected.

Is this a regression?

Unsure — remoteControlAtStartup was set for the first time on this machine while
diagnosing why terminal sessions don't auto-connect, so I have no prior-version
comparison for this combination.

Claude Code Version

2.1.217 (bundled in desktop app) / 2.1.218 (Homebrew CLI)

Platform

Claude Desktop app 1.24012.1 (prod, commit 0adcaed55041a881be363f2c4a4729f67a8b27d7,
built 2026-07-21)

Operating System

macOS (Darwin 25.5.0, Apple Silicon)

Related

• #77915 — the unguarded session_url read this disable lands on
• #78336 — the toggle left ON after the failed disconnect