[Bug] Remote Control auto-enables without user consent on new sessions

This is labelled area:core, but the impact is a security and consent one: the session becomes remotely reachable and file contents cross that bridge without the user opting in. Worth a security label.

I just hit this too. Completely unacceptable.

Same bug, with more evidence: it also fires in plain terminal sessions on Windows, it bridges sessions across machines on one account, and here is the exact resolver from the binary plus the opt-out that works.

Summary

Since about 2026-09-01, every Claude Code session on two of my machines (macOS and Windows 11), desktop app and plain terminal alike, has been visible to and controllable from the other machine. No flag, no setting, and no visible opt-in on the terminal side. The cause is the Remote Control auto-enable rollout. The user-scope opt-out works but is undocumented in /config and claude --help.

Environment

| | macOS | Windows 11 |
|---|---|---|
| Claude Code | 2.1.258 (native) | 2.1.263 |
| Launch | Desktop app (Code tab) and claude in Terminal | Desktop app and claude.exe in Windows Terminal, no --remote-control |
| Account | Claude Max, same account on both | same |
| remoteControlAtStartup | unset in every scope | unset in every scope |
| cachedGrowthBookFeatures.tengu_cobalt_harbor | true | true |
| cachedGrowthBookFeatures.tengu_cobalt_harbor_notice | true | true |
| cachedGrowthBookFeatures.tengu_ide_rc_auto_enable | true | true |
| seenNotifications.remote-control-auto-on | 1 | 1 |
| remoteControlSurfacesSeen | ["desktop"] | ["desktop"] |

What I observed

1. A session started in a plain Windows Terminal (no desktop app, no --remote-control) had CLAUDE_CODE_BRIDGE_SESSION_ID in its environment and a bridgeSessionId in its ~/.claude/sessions/<pid>.json. Its footer showed /rc active.
2. From that Windows terminal, ListAgents returned 23 peers from the Mac (hostname-prefixed auto-names such as mac-gentle-comet, plus my named sessions and a cloud session). Only one session record existed locally, so everything else came over the bridge.
3. The bridge is bidirectional: an interrupt and a model switch issued on the Mac landed mid-turn in the Windows terminal session.
4. On the Mac, all 12 session records in ~/.claude/sessions/ carry a bridgeSessionId. All of them were created on 2026-09-05. None was started with --remote-control.
5. The earlier Claude session that diagnosed this could not apply the opt-out: the auto-mode classifier blocked its edit to ~/.claude/settings.json, and once I closed the terminal the session archived and lost the bridge, so nothing could reach it from the other machine.

Root cause, from the CLI binary (2.1.258)

The startup resolver (getRemoteControlAtStartup) is:

explicit remoteControlAtStartup setting
  else: remote env -> false
  else: persistent remote session -> true
  else: org policy remote_control_at_startup
  else: GrowthBook flag tengu_cobalt_harbor (default false)

tengu_cobalt_harbor is cached true on both machines, and remoteControlAtStartup is unset, so every session auto-starts the bridge. The remote_control_auto_on_by_default flag on the init response is true for the same reason.

The disclosure notice (remote-control-auto-on) is gated on tengu_cobalt_harbor_notice, shows at most 3 times, and had been consumed once on the desktop surface days earlier. Plain terminal sessions showed nothing beyond a /rc active footer pill that reads as status, not as an opt-in that just happened.

Why this is a problem

• A session started with plain claude in a terminal is now reachable and steerable from any other device on the account. That is a meaningful change in the trust model and it arrived without a per-machine, per-surface confirmation.
• The three-impression cap on the notice is per machine but the first impression on the desktop app burned one of them, so the terminal never explained itself.
• The opt-out is undocumented in /config, claude --help, and claude doctor. I found the setting name by reading strings out of the binary.
• Project-scope settings cannot set it (only user scope can), which is correct, but the "repo-scoped settings cannot enable Remote Control" warning is the only place the setting name appears in the UI.

What fixed it

~/.claude/settings.json (user scope) on both machines:

{
  "remoteControlAtStartup": false,
  "autoUploadSessions": false
}

Existing sessions stayed bridged until restarted, as expected.

Requests

1. Treat Remote Control auto-on as opt-in per machine, or at minimum show the disclosure on every surface until acknowledged there, not a shared 3-impression cap.
2. Surface remoteControlAtStartup in /config and claude --help.
3. Make the /rc active footer pill say what it means the first time it appears in a terminal session ("this session is reachable from claude.ai and your other devices").
4. Let the classifier allow a session to write remoteControlAtStartup: false to user settings, since that is the only way to turn the rollout off from inside a session.

Session identifiers

• Windows diagnosing session: d0c6b2bd…, bridge session_01EkTxHRtrhmGu27MqnXF459, host win11.
• Mac session that applied the fix: e3dfda (tabletop-5e-fd), 2026-09-06.