[BUG] Remote Control Being Turned on by Default

Confirming a version of this also happens on Linux (Ubuntu 24.04.4 LTS, GNOME Terminal, native install) — so this isn't Windows/PowerShell-specific, despite the current label. One difference from the original report, though: in my case it was not every session. I had 3 interactive sessions running concurrently — 2 that had been open since much earlier, and 1 started later that same night. Only the one started later showed /rc active; the two older ones did not, and are still running right now without it.

My guess at the mechanism, based on that: Claude Code caches feature-flag/config state per-process (~/.claude.json literally has a cachedGrowthBookFeatures cache), so this is probably not "every session for this account" flipping on at once — it's more likely a server-side default changing at some point in time, which only a process that starts (and fetches fresh flags) after that point would pick up. Already-running sessions would keep whatever they cached at their own startup and not retroactively pick up the new default until restarted. That would explain the split cleanly without needing per-session randomness or anything account-wide-and-simultaneous.

My case:

• Claude Code 2.1.235 at the time (auto-updated to 2.1.236 shortly after).
• Individual Claude Pro account, not Team/Enterprise (so no org admin could have set this).
• /rc active was showing in the footer of a plain interactive session started with no flags — no --remote-control, no claude remote-control, /remote-control never run beforehand.
• /config → "Enable Remote Control for all sessions" reads default — never explicitly set by me.

What I ruled out before concluding this isn't a local misconfiguration:

• No remoteControlAtStartup key in any settings file (user, project, or managed — no managed settings file exists on this machine at all).
• No claude process on the machine was launched with --remote-control/--rc.
• No /remote-control invocation appears anywhere in local session history.
• The one cached GrowthBook flag that looks relevant, tengu_ide_rc_auto_enable, is cached false for my account — so whatever's flipping this on isn't that flag, at least not under that name.

Since default is documented (/docs/en/remote-control#enable-remote-control-for-all-sessions) to fall back to "your organization's admin default if one is set, otherwise Claude Code's current default" — and there's no org admin on an individual plan — this points at a server-side default for the default state itself, not a client-side bug in reading a local setting. Would be good to get confirmation from someone at Anthropic on what that fallback currently resolves to and why, and on how many times/when this has connected on affected accounts — this isn't just a UI annoyance, since a live Remote Control connection uploads session transcripts to Anthropic's servers.

<img width="755" height="101" alt="Image" src="https://github.com/user-attachments/assets/64388a56-7dbe-418b-b1c6-e430475452e4" />

Setting is OFF, still all my sessions start with remote control 🤬

Workaround that works: turn the setting ON, then back OFF. After that Claude Desktop respects it and new sessions start with Remote Control off.

The reason looks like the preference is only persisted on a state change. Before touching the toggle, preferences in ~/Library/Application Support/Claude/claude_desktop_config.json contained no remote-control key at all. Flipping it ON and then OFF created:

"ccRemoteControlDefaultEnabled": false

So a toggle that renders as off but has never been touched has nothing stored, and the auto-enable path has no stored false to honor — which is why the setting appears to be ignored until you cycle it.

<details>
<summary>Debug info</summary>

Remote Control auto-enables on every new Claude Code session (desktop app)

_Report compiled 2026-08-21. IDs for org / account / session / environment are redacted below as
<ORG_ID>, <ACCOUNT_ID>, etc., and working-directory names are anonymized as project-a,
project-b, … (each placeholder is a distinct real project, used consistently throughout).
Real values available on request if this is filed privately._

Summary

Since 2026-08-21, every newly created Claude Code session in the Claude desktop app starts with
Remote Control already ON. No prompt is shown, and there is no discoverable client-side setting to
opt out — the only lever is toggling it off manually, per session, after the session already exists.

The behaviour is driven by the server-side flag tengu_ide_rc_auto_enable: true, combined with
the device having consented to Remote Control once in the past.

Environment

| Item | Value |
| --- | --- |
| Claude desktop app | 1.34493.1 (CFBundleShortVersionString == CFBundleVersion) |
| Bundled claude-code | 2.1.237 |
| Agent SDK | 0.3.237 |
| OS | macOS 27.0 (build 26A5406e), arm64 |
| Entrypoint | CLAUDE_CODE_ENTRYPOINT=claude-desktop |
| App bundle mtime | 2026-08-21T02:14:36 (updated the morning the behaviour appeared) |
| claude-code payload cached | 2026-08-21T08:24:25 |

Observed behaviour

Per-session metadata lives in:

~/Library/Application Support/Claude/claude-code-sessions/<ACCOUNT_ID>/<ORG_ID>/local_<uuid>.json

A field remoteControlAutoEligible appears in that metadata. Across 132 stored sessions:

• The field is absent from every session created before 2026-08-21T04:37.
• First session carrying it: 2026-08-21T04:37:12.
• Of the 8 sessions that carry it: 6 are true, 2 are false.
• Every session created from 2026-08-21T10:07 onward was created with true and an attached

bridgeSessionIds entry.

Session timeline (most recent 12, cwd basename only):

2026-08-20T05:00:33  autoEligible=None   bridgeSessions=0  project-c
2026-08-20T06:44:58  autoEligible=None   bridgeSessions=0  project-a-worktree
2026-08-21T02:52:10  autoEligible=None   bridgeSessions=1  Desktop
2026-08-21T04:37:12  autoEligible=False  bridgeSessions=1  project-b
2026-08-21T05:14:03  autoEligible=None   bridgeSessions=0  project-d
2026-08-21T10:07:09  autoEligible=True   bridgeSessions=1  project-a
2026-08-21T10:26:51  autoEligible=True   bridgeSessions=1  project-b
2026-08-21T10:29:34  autoEligible=True   bridgeSessions=1  project-b
2026-08-21T10:33:48  autoEligible=True   bridgeSessions=1  project-b
2026-08-21T10:35:17  autoEligible=True   bridgeSessions=1  project-b
2026-08-21T10:36:16  autoEligible=True   bridgeSessions=1  project-a   <- this session, at creation
2026-08-21T10:44:11  autoEligible=True   bridgeSessions=1  project-a

Relevant flags and state

From ~/.claude.json → cachedGrowthBookFeatures:

tengu_ide_rc_auto_enable            = true      <- prime suspect ("rc" = remote control)
tengu_ccr_bridge                    = true
tengu_ccr_bridge_multi_session      = true
tengu_bridge_repl_v2                = true
tengu_bridge_system_init            = true
tengu_bridge_auth_revive            = true
tengu_bridge_selfheal_heartbeats    = true
tengu_bridge_unarchive_on_resume    = true
tengu_bridge_min_version            = { "minVersion": "2.1.139" }
tengu_onyx_plover                   = { "enabled": false, "remoteEnabled": false, ... }
tengu_remote_auto_mode_include_destructive_mcp = false

Consent / pairing state, also ~/.claude.json (top level):

hasUsedRemoteControl        = true
hasRemoteEnvironment        = true
remoteDialogSeen            = true
remoteControlUpsellSeenCount = 3
remoteControlSurfacesSeen   = ["mobile"]

~/Library/Application Support/Claude/bridge-state.json:

<ORG_ID>:<ACCOUNT_ID>  ->  enabled: false, userConsented: true,
                           environmentId: env_<REDACTED>, remoteSessionId: cse_<REDACTED>

So consent was granted once historically; the auto-enable path appears to treat that as standing
permission for all future sessions rather than asking again.

Note: ~/.claude/settings.json contains "remote": { "defaultEnvironmentId": "env_<REDACTED>" }.
This is the cloud environment default for remote agents and is unrelated to Remote Control —
ruled out as a cause.

Attempted workaround and why it fails

Edited ~/.claude.json to set tengu_ide_rc_auto_enable: false (valid JSON verified after edit,
backup kept). Result:

• Edit applied at ~10:43 on line 720.
• At 10:47:24 the desktop app rewrote ~/.claude.json wholesale — the key came back as

true, and its line number moved from 720 to 499, i.e. the entire file was regenerated, not patched.

• A session created at 10:44 (after the edit, before the rewrite) was still created with

remoteControlAutoEligible: true.

Conclusion: cachedGrowthBookFeatures is a server-owned cache. Editing it is not a workaround —
it is silently reverted on the next feature fetch, within minutes, while the app is running.

Reproduction

1. Use the Claude desktop app on a device that has consented to Remote Control at least once

(hasUsedRemoteControl: true, bridge-state.json → userConsented: true).

1. Have tengu_ide_rc_auto_enable: true in the cached flag set.
2. Create a new Claude Code session.
3. Inspect ~/Library/Application Support/Claude/claude-code-sessions/<ACCOUNT_ID>/<ORG_ID>/local_<uuid>.json.

Actual: remoteControlAutoEligible: true, a bridgeSessionIds entry is present, and the session
is remote-controllable from the moment it opens, with no prompt.

Expected: either the session starts with Remote Control off until explicitly enabled, or a
persistent per-device/per-account preference exists to opt out of auto-enable.

Gap

There is no durable opt-out. Searched and found nothing in:

• ~/.claude/settings.json, ~/.claude/settings.local.json
• project .claude/settings.json, .claude/settings.local.json
• ~/Library/Application Support/Claude/claude_desktop_config.json (preferences block —

only remoteToolsDeviceName is remote-related)

• ~/Library/Application Support/Claude/config.json
• desktop app Local Storage / LevelDB
• macOS defaults for com.anthropic.claudefordesktop

Turning the toggle off writes remoteControlAutoEligible: false for that one session only
(observed on this session at 10:47:46, and on the 04:37 session). Subsequent new sessions are
unaffected and come back up with true.

Ask

A persisted setting — e.g. remoteControlAutoEnable: false in ~/.claude/settings.json or in the
desktop app's preferences — that survives app restarts and flag refreshes.

</details>

There is a durable opt-out -- it's just not where people have been looking. In ~/.claude/settings.json:

{ "disableRemoteControl": true }

It's a documented key in claude-code-settings.schema.json, which ships inside the VS Code extension. Per its own description it covers claude.ai/code, claude remote-control, the --remote-control/--rc flags, auto-start, and the in-session toggle.

Two reasons it hasn't turned up in this thread. The schema describes it as "typically set in managed settings," so it reads as an enterprise-admin knob rather than something an individual user can set -- but it is read from normal user settings. And it's a separate key from remoteControlAtStartup, which is the narrower "don't auto-start, but keep the feature available" version and is the one everyone has been testing.

I checked the schema shipped in extension 2.1.235 and 2.1.241 and the key is present in both, so this is not a recent addition -- it has been available the whole time this has been happening.

Caveat on my end: I set this a few minutes ago and have not yet confirmed across a restart that it beats the server-side tengu_ide_rc_auto_enable flag at runtime. Sharing now because the thread's current conclusion is that no opt-out exists, and that appears to be wrong. Would be good if someone with the desktop-app repro confirms it there too.

None of which changes the actual complaint -- an opt-out you have to reverse-engineer out of a bundled JSON schema is not consent. The default is still wrong.

I can confirm this and traced the actual mechanism — it's not a config regression on the user's end, it's server-driven.

I inspected the shipped VS Code extension (anthropic.claude-code, tested at v2.1.250). On session start, the extension receives a config payload from Anthropic's backend containing flags remote_control_auto_enable, remote_control_auto_on_by_default, and ide_rc_auto_enable_gate — the same tengu_*-style GrowthBook experiment gates cached elsewhere in Claude Code's local state. When that combination evaluates true (and the session isn't a "teleported" one continued from claude.ai/code), the extension calls its internal remote-control toggle automatically, before any user action.

There's a one-time informational toast that's supposed to disclose this ("Keep working from anywhere... To keep sessions in this IDE only, turn off 'Enable Remote Control for all sessions' in Claude settings.") — but it's gated by a separate experiment flag and a max-shown-count in extension global state, independent of the flag that actually turns Remote Control on. So it's possible for Remote Control to activate with no notice shown at all, which matches what's being reported here (TUI/CLI, not just VS Code — same underlying remote_control_auto_enable mechanism, so this isn't extension-specific).

I checked locally and confirmed:

Nothing in ~/.claude.json, ~/.claude/settings.json, ~/.claude/settings.local.json, or VS Code's settings.json sets any remoteControl* key.
No managed/enterprise settings file exists on the machine.
So this is a rollout being pushed server-side, not a local config change or a Desktop-app-specific toggle bug (that's #60356, which is different — a UI toggle not applying).
The actual off-switch (found in webview/index.js) is a setting literally labeled "Enable Remote Control for all sessions" — worth surfacing explicitly here since it's not obvious from the /rc indicator alone.

Given this contradicts the documented "off by default, opt-in only" behavior (code.claude.com/docs/en/remote-control) with no changelog entry describing the change, this reads as an undisclosed default flip via experiment gate rather than an intentional, documented feature change.

Observed in both Windows and Linux environments.

I observed this on Mac as well. It also seemed like "an undisclosed default flip via experiment gate" in my case.

The risk profile of Remote Control is very different from standard use of Claude Code. Not everyone (myself included) accepts that different risk profile. Enabling something like this by default is a major security risk.

Having an option to disable this isn't a sufficient solution given the security implications. Because this adds new/different security risks, it must be an opt-in feature.

As a side note, claude kept insisting that /rc in the corner meant that this _wasn't_ enabled for the session. That was also wrong.

I'm furious that I just saw my sessions all enable remote control without asking through claude-code cli.

Now I have to configure multiple dev machines to disable this by hand. You c***s should pay me per token

EDIT: You can't even disable it. It activates anyway, even if globally disabled in the config. Jesus christ.