Remote Control: no way to enable Claude in Chrome for spawned sessions

[ykdojo]

Claude Code 2.1.201 (CLI, macOS), extension installed and working in terminal sessions.

Sessions spawned from the Claude app / claude.ai/code via claude remote-control never get the claude-in-chrome tools:

• The "Enabled by default" setting from /chrome isn't inherited, even by a server started after it was set.
• claude remote-control --chrome fails with Error: Unknown argument: --chrome.

Request: accept --chrome on claude remote-control, or have spawned sessions inherit the "Enabled by default" setting.

[treklight]

+1, hit this on Windows 11 (CC 2.1.212, Brave). Adding diagnostics that may help scope it:

• RC-spawned sessions never receive the mcp__claude-in-chrome__* tools — verified with a clean test: RC server restarted with the browser open and the extension connected (a desktop session's list_connected_browsers confirmed the connection), fresh RC session spawned 2 minutes later, ToolSearch returned zero claude-in-chrome tools.
• claude --chrome exists on the interactive CLI, but claude rc --help exposes no chrome flag, and claudeInChromeDefaultEnabled: true does not apply to RC spawns.
• Headless children DO get the bridge: claude -p "<task>" --chrome successfully drives the logged-in browser — but the first browser action hits the "Claude in Chrome requires permission." gate, which cannot be satisfied non-interactively (--allowedTools "mcp__claude-in-chrome", settings allow rules, and --permission-mode bypassPermissions all fail to clear it). Only a PermissionRequest/PreToolUse hook returning permissionDecision: "allow" clears it headlessly.

Workaround we use: RC sessions shell out to a wrapper that runs claude -p --chrome with a settings file containing that hook. Works, but native support (a --chrome passthrough on claude rc, or an allow-rule surface for the chrome permission gate) would be much better.

🤖 Generated with Claude Code

[mickey-mikey]

+1, independently reproduced on Windows 11 Pro (10.0.26200), Claude Code 2.1.225 (CLI, not desktop).

While trying to reproduce #74931 (the account-level "active worker" eviction) in plain CLI sessions rather than the desktop app, I ran into this gate as a separate blocker. Method: launched a fully independent claude -p ... --chrome process (its own PID/session ID, not a subagent of an existing session) to act as a genuinely new headless session — twice, once from a scratch directory and once from the target project directory with --permission-mode auto to match an already-frictionless interactive session running in that same directory.

Both times:

• list_connected_browsers (read-only) succeeded immediately, no prompt.
• The first state-mutating call, tabs_context_mcp, was hard-blocked: "Claude in Chrome requires permission." / decision_reason_type: "other".
• Neither --allowedTools naming the exact tool, nor --permission-mode auto, cleared it — consistent with @treklight's report above that --allowedTools, settings allow rules, and --permission-mode bypassPermissions all fail to clear this specific gate.

So the second (never-before-connected) session never touched the bridge at all in my test — which also means it's a distinct mechanism from #74931, not a duplicate: #74931 is about an already-connected interactive session getting evicted by a newer one; this is a hard consent wall that stops a fresh headless session from ever connecting in the first place. Both need fixing before scheduled/unattended browser automation is reliable.

🤖 Generated with Claude Code