Remote Control: sessions register a cloud slot without the documented opt-in, and the disclosure is capped and probabilistic

Remote Control is enabled by a server-side flag on installs that never opted in

Version: Claude Code CLI 2.1.245
Platform: Linux (Debian 12), per-user install at ~/.local/share/claude
Auth: claude.ai subscription, no organization, no managed settings

Summary

A feature that connects my local development machine to a remote control plane was
switched on by a server-side flag. I never enabled it, never used it, and the in-product
notice that would have told me about it is designed to stop showing itself after three
appearances while the feature remains active.

Evidence

All of the following is from my own machine and from your shipped 2.1.245 bundle.

1. The default is decided by a server flag, not by me.

function resolveCcrAutoConnectDefault(){
  if (isRunningInRemoteEnvironment()) return {value:false, source:"remote_env"};
  if (isPersistentRemoteSessionEnabled()) return {value:true, source:"persistent_remote_session"};
  let e = policy("remote_control_at_startup");
  if (e !== undefined) return {value:e, source:"org_policy"};
  return {value: flag("tengu_cobalt_harbor", false), source:"growthbook"};   // <-- reached
}

The in-code default is false. On my install the flag is server-set:

cachedGrowthBookFeatures.tengu_cobalt_harbor        = True
cachedGrowthBookFeatures.tengu_cobalt_harbor_notice = True

2. I never expressed any preference.

remoteControlAtStartup   absent from ~/.claude.json
remoteControlAtStartup   absent from ~/.claude/settings.json
hasUsedRemoteControl     absent
remoteControlMachineId   absent
/etc/claude-code         does not exist (no org policy)

Every local input was empty. The feature was on regardless.

3. The disclosure is built to expire while the feature persists.

on = "remote-control-auto-on", Og = 3;
if ((seenNotifications?.[on] ?? 0) < Og) show();

My file: seenNotifications["remote-control-auto-on"] = 3. The cap was reached, so the
notice permanently stopped appearing.

There is a second capped surface — the status badge itself:

var UG = "rc-active-badge", f9e = 5;
xye() { return (seenNotifications["rc-active-badge"] ?? 0) < 5 }
iN(e) { return e === "/rc active" && !xye() ? "/rc" : e }

Past five impressions the badge stops reading "/rc active" and shows a bare "/rc" —
the word active is dropped. My file records rc-active-badge: 5, i.e. at the cap.

Both caps match the server-delivered flag config, which also makes each impression a
coin flip:

tengu_rc_long_turn_nudge  = {"thresholdSec":10, "probability":0.5, "maxImpressions":5}
tengu_rc_permission_nudge = {"afterPromptCount":2, "probability":0.5, "maxImpressions":3}

So the disclosure is capped, probabilistic (probability: 0.5 — shown roughly half the
time it is eligible), and self-suppressing, while the behaviour continues indefinitely. It is
also recorded in seenNotifications, the same structure that holds informational toasts:
there is no consent dialog and no stored record of an affirmative choice anywhere in local
configuration.

4. The control is hidden behind a gate, and its neutral value is not neutral.

...gate() ? [{ id:"remoteControl",
               label:"Enable Remote Control for all sessions",
               value: remoteControlAtStartup === undefined ? "default" : String(...),
               options:["true","false","default"] }] : []

The entry is wrapped in a visibility gate. Its displayed value for an unconfigured user
is the word default, which reads as "not switched on" and in fact means "defer to
tengu_cobalt_harbor" — currently on. A tri-state control whose innocuous-looking value
silently delegates to a remote flag is a dark pattern.

5. The off switch is misattributed to an authority I do not have.

Setting disableRemoteControl: true produces:

Error: Remote Control is disabled by your organization's policy
       (managed setting `disableRemoteControl`).

I have no organization and no managed settings. The key is on your own restrictive
allowlist and is honoured from user settings, yet every string around it points at
/etc/claude-code/managed-settings.json — a root-owned path. For software installed
entirely under $HOME with no privilege escalation, the documentation and messaging steer
users toward believing that turning the feature off requires administrative rights. It does
not, and saying so wastes users' time and discourages opt-out.

6. Ordinary sessions register a cloud session slot automatically.

claude remote-control --help documents an explicit, opt-in model:

Remote Control runs as a persistent server that accepts multiple concurrent sessions in the current directory. Run this command in the directory you want to work in, then connect from your phone or a browser.

Observed behaviour differs. ~/.claude.json carries a live replBridgePlaceholders map,
and session transcripts carry JSONL entries of "type":"bridge-session" recording a
bridgeSessionId. On two machines, across seven distinct sessions, these appeared with the
remote-control command never run and no CLAUDE_REMOTE_CONTROL* variable set. Decoding
slot creation against process start:

process start 07:13:00Z  ->  slot created 07:13:01.834Z   (~1.8 s)
process start 07:18:27Z  ->  slot created 07:18:28.999Z   (~2.0 s)

The flag cache was written at 07:18:28.519Z — roughly half a second before the second slot
was created. Flag fetch and slot registration occur in one startup sequence.

Earliest such record I can still see locally is 2026-08-20 (v2.1.237); transcript
retention, not the behaviour, sets that floor. A dated system message of 2026-08-24
independently records an instance that had already held Remote Control for three days.

Supporting flags in the same payload are all true — tengu_ccr_bridge,
tengu_bridge_selfheal_heartbeats, tengu_bridge_auth_revive, tengu_ccr_reconnect_beat,
tengu_bridge_unarchive_on_resume — and tengu_bridge_poll_interval_config sets a 2000 ms
poll and a 180000 ms heartbeat. The channel is continuously maintained, not opened on demand.

I am not asserting that any party connected to these slots; client-side evidence cannot show
that. The defect is that the documented opt-in model and the shipped default do not match.

What I am asking for

1. Change the default. tengu_cobalt_harbor must not enable a remote control plane on a

user's machine absent an affirmative, logged opt-in.

1. Remove the notice cap, or keep a persistent indicator for as long as the feature is on.
2. Render the control unconditionally, and label the unconfigured state truthfully —

"on (set by Anthropic)" rather than "default".

1. Correct the error string and the documentation to state that disableRemoteControl

works from user settings and requires no root.

1. Tell me plainly what was transmitted from these machines while the feature was active,

and provide a means to have it deleted.

1. Reconcile claude remote-control --help with actual behaviour, or stop registering

session slots for users who never ran the command.

Standing request

Do not re-enable this by flag. I have set disableRemoteControl: true, which your code
evaluates before the flag, and I expect that to be respected in all future versions.