What
Running claude remote-control with root-level CLI options now fails with a clear error naming the options it refuses, rather than passing your whole argv through to the bridge and behaving unpredictably. Unknown options and extra arguments are still allowed through to the bridge itself.
Details
- The subcommand disables its own help option and asks the loaded bridge module which root options it refuses.
- If any refused option was supplied, it errors with a generated message and never starts the bridge.
- Reachable on every build; no flag involved.
Evidence
rootOptionsRemoteControlRefuses
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Names in the bundleclaude remote-control
The entry above is what we published on the day. These lines were added later, as Anthropic's own pages caught up, and they sit beside the original rather than replacing it.
Confirmed since
Anthropic's documentation has since written up claude remote-control, on Claude Code changelog.
* Fixed Remote Control sessions served by `claude remote-control` showing a generated name instead of their session title in `ListAgents`changelog see the edit
Added since
A small documentation edit on Continue local sessions from any device with Remote Control touched a line naming claude remote-control after this was published.
All traffic travels through the Anthropic API over TLS, the same transport security as any Claude Code session. The connection uses multiple short-lived credentials, each scoped to a single purpose and expiring independently. When a `claud…remote-control see the edit
Two sources agreeTwo things we can check say the same as this entry.
Anthropic's documentation agrees
A small documentation edit on Continue local sessions from any device with Remote Control touched a line naming claude remote-control after…
Anthropic's release notes agree
Fixed claude remote-control rejecting its own flags (e.g. --spawn, --name) when a global flag or a wrapper-injected option precedes the…