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.**

```js
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.**

```js
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:

```js
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.**

```js
...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.
2. Remove the notice cap, or keep a persistent indicator for as long as the feature is on.
3. Render the control unconditionally, and label the unconfigured state truthfully —
"on (set by Anthropic)" rather than "default".
4. Correct the error string and the documentation to state that `disableRemoteControl`
works from user settings and requires no root.
5. Tell me plainly what was transmitted from these machines while the feature was active,
and provide a means to have it deleted.
6. 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.

Start with `claude remote-control --help` and compare its documented opt-in behavior with `~/.claude.json` and the session transcript `bridge-session` records. Inspect the shipped bundle around `resolveCcrAutoConnectDefault`, `remote-control-auto-on`, and `rc-active-badge`; done means the startup behavior, disclosure, settings messaging, and help text consistently reflect explicit opt-in.

Scritto dal modello di indicizzazione a partire dal testo della issue.