Remote Control should be opt-in, not on by default
Summary
Remote Control appears to be on by default. My ~/.claude/settings.json has noremote-related key, and I never enabled the feature, yet the session reports
Remote Control as available. I did not choose this, and I would not have.
Why a default-on remote channel is the wrong default
Remote Control is a fan-out control channel over developer machines. A single
vulnerability in the account-side or relay-side component does not compromise
one machine — it compromises every machine running a Claude Code session
under that account, with whatever permissions that session holds. That is a
materially larger blast radius than a local CLI bug, and it is exactly the
shape of thing that should require an explicit, per-machine opt-in.
Security features that expand reach should fail closed. This one fails open.
Compliance
Some environments prohibit remote control of developer workstations. A feature
that is on unless discovered and disabled makes it difficult to enforce such
policies. The disabled state should be explicit, verifiable, and enforceable
rather than dependent on individual users discovering the feature.
Ask
- Make Remote Control opt-in — off unless explicitly enabled on that machine.
- Provide a documented hard kill switch honoured at startup (settings key and
env var) that the account side cannot override.
- Support managed/enterprise settings enforcement so an org can disable it for
all users.
- Publish the threat model: what the relay can see, what it can execute, how
sessions are authenticated, and what an account compromise permits.
Environment
- Claude Code 2.1.247
- macOS (darwin 25.6.0)
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗