Group of 4 Use it now Notable
A new --chrome / --no-chrome flag controls whether spawned and Remote Control sessions can use Claude in Chrome
What
- Spawning or reattaching a session now supports a
--[no-]chromeflag that controls whether "Claude in Chrome" is available for that session, defaulting to the machine's own Chrome setting. - The
claude remote-controlcommand's argument parser also gained matching--chrome/--no-chromeflags. - When Remote Control starts with
--chrome, Claude Code now checks whether an enterprise MCP policy or a denied-MCP-servers list blocks the Claude-in-Chrome MCP server, and exits with an error instead of silently proceeding if it's blocked. - Child sessions spawned by Remote Control now inherit the
--chromesetting from their parent, so the option is passed through consistently.
Why
This gives explicit, per-session control over whether Claude in Chrome is enabled, and ensures that enterprise policies restricting MCP servers (which Claude in Chrome relies on) are respected rather than bypassed when Remote Control starts with Chrome access requested.
Names in the bundle--chrome--no-chrome
Documented inclaude-code/cli-reference
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 --no-chrome, on CLI reference.
| `--no-chrome` | Disable [Chrome browser integration](/docs/en/chrome) for this session | `claude --no-chrome` |cli-reference see the edit
Confirmed since
Anthropic's documentation has since written up --chrome, on CLI reference.
| `--chrome` | Enable [Chrome browser integration](/docs/en/chrome) for web automation and testing | `claude --chrome` |cli-reference see the edit
One source agreesOne thing we can check says the same as this entry.
Anthropic's documentation agrees
Anthropic's documentation has since written up --chrome, on CLI reference.