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

+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

+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

+1, still reproducible on Windows 11 Pro (10.0.26220), Claude Code 2.1.263, Chrome 152, Claude Desktop with Remote Control on. Extension installed and working in plain terminal sessions.

Concrete case today (2026-09-06): from a Remote Control session I asked Claude to post a feature request to a Discourse forum I am already logged into in Chrome. The session had zero mcp__claude-in-chrome__* tools in its registry, so it could not drive the logged-in tab. Every fallback is closed too:

• Chrome 136+ ignores --remote-debugging-port on the default profile, so puppeteer cannot attach to the real logged-in browser.
• Importing the browser's cookies into a fresh automation profile is (correctly) refused by the auto-mode permission classifier.

Net effect: "post this on my behalf to a site I am logged into" is impossible from any spawned session, even though the same request works in a claude --chrome terminal. Request stands as filed: accept --chrome on claude remote-control, or let spawned sessions inherit the /chrome "Enabled by default" setting.