Claude in Chrome: per-domain permission has no prompt or settings surface, silently blocks all access

Environment

• Claude Code desktop app (macOS)
• Tool: mcp__claude-in-chrome__* (Browser pane / "Claude in Chrome")

What happened
Any action on a specific domain (app.qbo.intuit.com, az.cwa.sellercloud.com) fails with:

• Permission denied for this action on this domain (from computer/screenshot)
• Permission denied for reading pages on this domain (from read_page)

navigate itself succeeds (the tab loads and shows the correct page title/URL), but every
subsequent interaction on that tab is denied. This happened both in an unattended scheduled
task run and in a live interactive session with the user watching the Chrome window the whole
time — no permission prompt, popup, or notification ever appeared for the user to approve.

What I expected
Either:

1. An on-demand approval prompt surfaces in Chrome (or the Claude Code app) the first time a

new domain is touched, which the user can click through, or

1. A settings/allowlist surface exists somewhere the user can proactively grant domains before

running a task (especially important for unattended scheduled tasks, which can never resolve
an in-the-moment prompt).

Neither exists as far as we could find.

Diagnostics performed to rule out other causes

• No MDM enrollment: profiles status → "There are no configuration profiles installed on

this system"; /Library/Managed Preferences/ doesn't exist.

• No Chrome enterprise policy directories under

/Library/Application Support/Google/Chrome/.

• No trace of a Claude/Anthropic extension anywhere in Chrome's own Local State file —

suggesting "Claude in Chrome" isn't a conventional installed Chrome extension, or at least
isn't discoverable that way.

• Claude Code's own permission settings (~/.claude/settings.json,

project .claude/settings.local.json) already list the mcp__claude-in-chrome__* tools as
broadly allowed, unscoped by domain — so it isn't Claude Code's local tool-permission system
blocking it.

• The org's signed policy file (policy-limits.json) only carries three unrelated flags

(allow_remote_control, allow_quick_web_setup, enforce_web_search_mcp_isolation) —
nothing about domain-scoped browsing.

So the gate appears to live inside the "Claude in Chrome" service's own runtime, with no
externally visible prompt, log, or settings surface.

Impact

• Blocks a scheduled/unattended task (a weekly accounts-payable sweep) from ever completing the

portion of its work that depends on those domains — it fails identically every run with no
way to pre-authorize.

• Blocks interactive use too, since no prompt ever surfaces even when the user is actively

watching the browser pane.

Ask
Please expose either an on-demand approval prompt or a persistent settings/allowlist for
per-domain "Claude in Chrome" access, and/or document where this gate actually lives if one of
these already exists and we simply couldn't find it.