ccRemoteControlDefaultEnabled: true not honored on restart — Remote Control resets to OFF every time

Status Closed — duplicate

Maintainer reply None cached

Activity 6 comments · opened Jun 13, 2026 · closed Aug 25, 2026

Bug Description

The ccRemoteControlDefaultEnabled preference in claude_desktop_config.json is set to true, but Claude Code Desktop (CC Desktop) resets Remote Control to OFF every time the app restarts. Users must manually click \"Turn on Remote Control\" for each session after every restart.

Expected Behavior

When ccRemoteControlDefaultEnabled: true is set, Remote Control should automatically be enabled on app startup — for all active sessions, or at minimum for the default/new session — without requiring manual interaction.

Actual Behavior

Remote Control is always OFF after restart regardless of the ccRemoteControlDefaultEnabled setting
The Remote Control state is not persisted to any config or session file on disk
Every restart requires manual re-enabling per session

Impact

This blocks true automation workflows. If any automated pipeline depends on Remote Control being active (e.g., headless agents sending messages to a CC Desktop session), a simple app restart breaks the entire pipeline and requires manual intervention to restore it.

Environment

macOS 12.6 (Monterey)
Claude Code Desktop (CC Desktop)

Config

// ~/Library/Application Support/Claude/claude_desktop_config.json
{
  "preferences": {
    "ccRemoteControlDefaultEnabled": true,
    "chicagoEnabled": true,
    "remoteToolsDeviceName": "leisureapplemacbook-local"
  }
}

Requested Fix

Either:

Honor ccRemoteControlDefaultEnabled: true and auto-enable Remote Control on startup, OR
Persist the per-session Remote Control state to disk so it survives restarts

View original on GitHub ↗

5 Comments

github-actions[bot] · 2 months ago

Found 3 possible duplicate issues:

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

leisureapple · 2 months ago

Noting that the referenced duplicates (#29929, #60356) are both closed, but the issue is still fully reproducible as of June 2026 on macOS 12.6. The ccRemoteControlDefaultEnabled: true setting has no effect on restart behavior. This is a blocking issue for automation workflows — any pipeline that relies on Remote Control being active breaks silently on every app restart. Please keep this open or reopen the original issues.

suetake6183 · 1 month ago

I can confirm this bug reproduces on a different setup as well:

Environment:

Claude Code Desktop 2.1.197 (macOS, Mac mini)

Reproduction:

claude_desktop_config.json → preferences.ccRemoteControlDefaultEnabled was already set to true
Started a brand new interactive session from Claude Desktop (not a restart, a fresh new session)
/remote-control was not active for the new session; running /remote-control manually reported it as unavailable in that environment

Additional data point:

~/Library/Application Support/Claude/bridge-state.json tracks Remote Control enablement per-session (keyed by an environment/local-session UUID pair), not as a single global toggle. Out of ~20+ concurrently running Claude Desktop sessions on this machine, only one had an entry in that file at any given time — suggesting the "default enabled" preference is not being propagated to newly created sessions at all, rather than just failing to persist across app restarts (as the original report describes).

Workaround that worked once:

Manually toggling "Enable remote control by default" OFF then ON again in Settings → Claude Code caused the next new session to pick up Remote Control correctly. Only tested once, so I can't yet confirm this is reliable — but it points at the toggle write triggering something that isn't happening automatically on session creation.

Happy to share more config/log details if useful for debugging.

MrKoopie · 1 month ago

Can confirm too. I have to manually enable it every time. CLI works like a charm, but desktop somehow always ignores it.

jrzmurray · 1 month ago

Confirmed on my end as well. Have there been any updates?

Showing cached comments. Read the full discussion on GitHub ↗