### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue+state%3Aopen+label%3Abug) 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: - `ccRemoteControlDefaultEna

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

Status Fixed / completed

Reported on v2.1.217

Maintainer reply None cached

Activity 3 comments · opened Jul 24, 2026 · closed Aug 5, 2026

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:

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.

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

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

default".

Add "remoteControlAtStartup": true to ~/.claude/settings.json.
Start a new session in the desktop app and send any message.
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)

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

View original on GitHub ↗

3 Comments

JnManso · 2 months ago

Windows datapoint that narrows this: the self-disable reproduces with only ccRemoteControlDefaultEnabled set. remoteControlAtStartup is not present anywhere on this machine, so "removing it resolves it" can't be the whole fix.

Verified absent from every layer:

~/.claude/settings.json — no remoteControl* key at all
~/.claude.json — only remoteControlUpsellSeenCount, hasUsedRemoteControl, remoteDialogSeen, remoteControlSurfacesSeen
project .claude/settings.json and .claude/settings.local.json
no %PROGRAMDATA%\ClaudeCode\managed-settings.json

And the verdict line agrees. All 184 rcAutoEnable lines across my rotated logs say the same thing, never explicit_settings:

[rcAutoEnable] verdict: enable=true source=explicit_pref

So there is a single owner, no collision between the two settings, and it still self-disables.

What the log shows

%APPDATA%\Claude\logs\main.log. Session created at 10:48:00, nothing toggled by hand at any point:

10:48:00 [info]  [rcAutoEnable] verdict: enable=true source=explicit_pref
10:48:00 [info]  Enabling remote control for session local_a49f6df5-…
10:48:10 [info]  [remote-control] bridge_state: ready
10:48:10 [info]  Remote control enabled: https://claude.ai/code/session_01M9nadR…
10:48:11 [info]  [remote-control] bridge_state: connected
…
10:48:50 [info]  LocalAgentModeSessions.getSupportedCommands: sessionId=undefined, cwd=undefined
10:48:50 [info]  [LocalPluginsReader] Found 1 local plugins
10:48:50 [info]  LocalSessions.sendMessage: sessionId=local_a49f6df5-…, messageLength=15, priority=next
10:48:50 [info]  Disabling remote control for session local_a49f6df5-…      <-- unprompted
10:48:51 [error] Failed to toggle remote control for local_a49f6df5-…: Cannot read
                 properties of undefined (reading 'session_url')

Two things worth flagging beyond the original report:

1. It is not once per session. The same session did it again 14 minutes later, with a byte-identical preamble:

11:03:00 [info]  LocalAgentModeSessions.getSupportedCommands: sessionId=undefined, cwd=undefined
11:03:00 [info]  [LocalPluginsReader] Found 1 local plugins
11:03:00 [info]  LocalSessions.checkTrust: cwd=<project dir>
11:03:00 [info]  LocalSessions.sendMessage: sessionId=local_a49f6df5-…, messageLength=15, priority=(default)
11:03:00 [info]  Disabling remote control for session local_a49f6df5-…
11:03:00 [error] Failed to toggle remote control for local_a49f6df5-…: Cannot read
                 properties of undefined (reading 'session_url')

2. Both disables are immediately preceded by getSupportedCommands: sessionId=undefined, cwd=undefined, and by a sendMessage with messageLength=15 — the same length as in the log in the issue body. That reads less like "the first user message" and more like a session-context refresh running with an undefined session handle, plausibly the same undefined object whose session_url is read one line later. Might be a cheaper place to guard than the toggle itself.

Not affected: restart

After quitting and relaunching the app, all four open sessions re-registered normally (11:03:55, 11:04:07, 11:04:27, 11:04:40), each getting a fresh session_… id. The broken path here is only the disable.

Versions: Claude Code 2.1.219 (bundled), Claude Desktop 1.24012.11, Windows 11 (10.0.26200) — both newer than the 2.1.217 / 1.24012.1 in the original report.

antrewmorrison · 2 months ago

Fixed in Claude Desktop 1.26832.0 (macOS build now available via the in-app updater): Remote Control transitions are now serialized per session, so the automatic connect and a /remote-control typed at the same time can no longer race and switch Remote Control back off. (The session_url error in your log was fixed separately in an earlier build.) The two auto-enable settings are also not competing owners — the Desktop preference is consulted first and the settings.json value only when it is unset.

If you still see a self-disable after updating to 1.26832.0 or later, please attach ~/Library/Logs/Claude/main.log around the toggle and we'll reopen.

github-actions[bot] · 18 days ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.