Remote Control should be opt-in, not on by default

Status Open
Reported on v2.1.247
Maintainer reply None cached
Activity 2 comments · opened Aug 27, 2026

Summary

Remote Control appears to be on by default. My ~/.claude/settings.json has no
remote-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

  1. Make Remote Control opt-in — off unless explicitly enabled on that machine.
  2. Provide a documented hard kill switch honoured at startup (settings key and

env var) that the account side cannot override.

  1. Support managed/enterprise settings enforcement so an org can disable it for

all users.

  1. 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)

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗