[BUG] Claude in Chrome MCP tools: "Navigation to this domain is not allowed" on all domains (v1.0.66)

Experiencing a related issue on macOS (Darwin 23.6.0) with v1.0.66.

The extension does prompt for site approval on the first domain in a session, and that domain works fine. However, when attempting to navigate to or interact with any additional domain in the same session, it returns "Navigation to this domain is not allowed" / "Permission denied for reading pages on this domain" — without ever showing an approval prompt for the second domain.

The approved sites settings page shows previously approved domains but provides no way to manually add new ones. The only workaround is starting a new session for each domain.

So it seems like the approval flow is limited to one domain per session rather than being completely broken — subsequent domains are silently denied without prompting.

I have the same issue any possible solution?

In PermissionManager-WI3FAKQw.js, the checkPermission method has: if(r && this.turnApprovedDomains.size > 0 && !this.isTurnApprovedDomain(r)) return {allowed: false, needsPrompt: false}. Once any domain is turn-approved, all other domains are hard-blocked with needsPrompt: false, so the user never gets prompted to approve them.

Workaround found (Cowork mode): In the Cowork chat's approval settings, change from "Ask for approval" (default, Spanish UI: "pide aprobación") to "Request approvals" (Spanish UI: "solicitar aprobaciones"). After toggling this, navigate / read_page / form_input / computer all started working immediately in the same session.

This aligns with @zoyth's finding about PermissionManager-*.js turnApprovedDomains sticky state — the default setting seems to lock the turn-approval state and never clear it, while the alternative path clears/bypasses it.

Request to Anthropic: (1) make "Request approvals" the default, or (2) document this toggle prominently in the Claude in Chrome troubleshooting guide. Currently the failure mode is silent (Permission denied by user with no prompt shown), which trains users to believe they're misconfiguring something when they aren't.

Environment: macOS, Chrome latest, Claude Desktop (Cowork mode), Claude in Chrome extension fcoeoabgfenejglbffodgkkbkcdhcgfn.

Workaround found (Cowork mode): In the Cowork chat's approval settings, change from "Ask for approval" (default, Spanish UI: "pide aprobación") to "Request approvals" (Spanish UI: "solicitar aprobaciones"). After toggling this, navigate / read_page / form_input / computer all started working immediately in the same session.

This aligns with @zoyth's finding about PermissionManager-*.js turnApprovedDomains sticky state — the default setting seems to lock the turn-approval state and never clear it, while the alternative path clears/bypasses it.

Request to Anthropic: (1) make "Request approvals" the default, or (2) document this toggle prominently in the Claude in Chrome troubleshooting guide. Currently the failure mode is silent (Permission denied by user with no prompt shown), which trains users to believe they're misconfiguring something when they aren't.

Environment: macOS, Chrome latest, Claude Desktop (Cowork mode), Claude in Chrome extension fcoeoabgfenejglbffodgkkbkcdhcgfn.

Still reproducing on Windows with the latest claude-code CLI and extension v1.0.68. The resolution @dmarketingllm mentioned likely applies to Cowork only.

Building on @zoyth's finding: the early-exit triggers because the CLI path sends permissionMode: "follow_a_plan" to the extension, which populates turnApprovedDomains and never clears it. A quick look at the bundle shows mcpPermissions-*.js has setTurnApprovedDomains calls but lacks any clearTurnApprovedDomains logic. Conversely, sidepanel-*.js has several clears. This explains why @teiguell's Cowork UI toggle resolves the issue there but does nothing for the CLI path.

Normal approval flow comes back if the early-exit @zoyth quoted is bypassed, since checkPermission then falls through to needsPrompt: true. A proper upstream fix would be great, such as defaulting the CLI to "ask" mode or mirroring the sidepanel's state-clearing logic in the MCP path.

I was wrong. 'Navigate' is working for me in Claude Code. read_page, javascript_tool, and find are still all blocked immediately.

Still an issue. Blocks so many use cases - how is this not fixed already?

<img width="904" height="383" alt="Image" src="https://github.com/user-attachments/assets/0c0d57b9-520b-4b76-983d-97e47214251f" />
Same issue

Still experiencing this on macOS with Claude Code CLI. The single-domain-per-session lock is blocking multi-domain workflows — in my case, I need to interact with both a production WordPress site and its dev environment (different subdomain) in the same session, and only the first domain works. The second domain is silently denied without any approval prompt.

Still an issue. Blocks so many use cases - how is this not fixed already?

I am wondering exactly the same. I had a scheduled task verifying some listings on a few websites, and it was running for a couple of weeks perfectly, but now its been almost a month that it has been failing, saying that I have blocked that website and need to approve it.

But like you all say, it makes absolutely no sense, I am not blocking anything, and there is no way to approve it. I am also baffled how this is not yet fixed, aka a BLOCKING HOTFIX, there are no "workarounds"...

Still reproducing as of 2026-05-29 — Claude in Chrome extension, Claude Code CLI (Opus 4.8), macOS.

Ran a clean multi-domain repro in a fresh MCP session (single tab group), testing each tool individually so silent denials couldn't hide behind a batch error:

First domain (example.com) — everything works:

navigate, get_page_text, read_page, find, javascript_tool — all ✅
Any second domain in the same session — hard-blocked:

navigate → en.wikipedia.org → Navigation to this domain is not allowed
navigate → github.com → same
navigate → iana.org → same
No approval prompt is ever shown for the second domain.
Opening a brand-new tab in the same group and navigating it to the second domain fails identically → the lock is session-wide, not per-tab.
Tools on the first domain keep working fine throughout, so the session itself is healthy — it's locked to whichever domain got approved first.
This lines up with @zoyth turnApprovedDomains sticky-state finding and @chiptuned note that the CLI path populates turnApprovedDomains but has no clearTurnApprovedDomains logic.

One change from my earlier comment ("navigate works, read_page/find/javascript blocked"): the surface has shifted — navigate itself is now the thing hard-blocked on any domain past the first. Same root cause, different symptom. Still no in-session workaround on the CLI path.

Source-level root cause (verified from the extension bundle on Windows)

I de-minified the shipped extension (fcoeoabgfenejglbffodgkkbkcdhcgfn, v1.0.75; same in the v1.0.74 mirror) and the "Navigation to this domain is not allowed" deny comes from an exclusive per-turn allowlist, not from the category blocklist and not from any Chrome host-permission check.

PermissionManager.checkPermission() (PermissionManager-BBDx9xIl.js), seeded by mcpPermissions-8PlHLvdl.js:

checkPermission(t, e, n) {
  const r = new URL(t).hostname.replace(/\.$/, "");
  // EXCLUSIVE: non-empty turn list + host off-list -> HARD DENY, no prompt
  if (r && this.turnApprovedDomains.size > 0 && !this.isTurnApprovedDomain(r))
    return { allowed: false, needsPrompt: false };
  ...
}

turnApprovedDomains is populated only from the session plan's allowedDomains under permissionMode === "follow_a_plan". When it's non-empty, any host not on it is hard-denied with { allowed:false, needsPrompt:false } — silent, no prompt, short-circuiting before the persisted store and the prompt fallback. Crucially, the gate never calls chrome.permissions.contains() and so never consults the <all_urls> grant that "On all sites" controls — which is exactly why "On all sites" does nothing here. (chrome.permissions.contains({origins:['https://example.com/*']}) returns true, but the extension never asks.)

Negative control (proves the gate, not the domain): in a separate ad-hoc session with no plan armed (empty turnApprovedDomains), navigate() to example.com and northcreekpethospital.com both SUCCEEDED — the very domains that hard-denied while a one-site plan was active. Same "On all sites", same Chrome. This reconciles "one domain per session" as "only the plan-approved domains are navigable." It also rules out the category blocklist: example.com is benign and denied anyway. The same gate, re-evaluated against the new origin, is why read_page/screenshot fail after a window.location workaround lands you on an off-plan host (MV3 content-script/debugger detach is a plausible compounding factor, but the visible error is the permission check's own string).

Highest-value fix: before the exclusive hard-deny, honor the live grant — await chrome.permissions.contains({ origins: [new URL(target).origin + '/*'] }) — and if it's true, fall through to ALLOW (or to a prompt) instead of silently denying. Equivalently, expose a user-settable allowed-domains list so personal-account users can pre-approve multiple domains. (Files: PermissionManager-BBDx9xIl.js / mcpPermissions-8PlHLvdl.js; v1.0.74 mirror PermissionManager-uCwrpbh7.js / mcpPermissions-O6s_WAiZ.js. Env: Windows, v1.0.75, site access "On all sites".)

Environment: Claude Code (Desktop app, Windows), model Opus 4.8, Claude in Chrome extension. Single local browser connection.

Repro (internal hosts replaced with placeholders — the relevant point is they're sibling subdomains of one parent domain):

mcp__Claude_in_Chrome__navigate → https://app.dev.example-corp.com/ → ✅ works (and every tool works on it: get_page_text, read_page, find, javascript_tool, screenshot)
navigate → https://app.stage.example-corp.com/ (sibling subdomain, same parent) → ❌ "Navigation to this domain is not allowed"
navigate → https://example.com/ → ❌ same error
No approval prompt ever appears for the blocked domains.
How this differs from the existing reports in this thread:

It is not "first domain in a fresh session wins." In a freshly reconnected session, navigating to the blocked subdomain first still fails, while the permitted subdomain works even when attempted after the failed one — so a specific domain is permitted and others aren't, order-independent.
Reproduced across three escalating resets, each confirmed as a brand-new connection (the connectedAt from list_connected_browsers changed every time):
Desktop app — disconnect → reconnect the Chrome connection
Chrome — toggle the extension off → on
Full machine reboot
In all three, the permitted subdomain works and the sibling/other domains fail identically.
The Claude sidebar / Cowork session (same browser, same machine) reaches the blocked domains fine — only the Claude Code MCP connection is restricted.
Net: on this Desktop-app setup there's no in-reach workaround — a given connection appears permanently scoped to one subdomain and won't admit siblings, surviving reconnect, extension toggle, and reboot.

Still reproducing on Claude desktop app (macOS), Claude in Chrome (Beta).
Settings → Claude in Chrome → "Default for all sites: Allow extension", Blocked sites: none.
mcp navigate to my own app domain (app.ppcoptimizerai.com) returns
"Navigation to this domain is not allowed" — every time, even in a freshly created MCP tab.
Reinstall / settings do not fix it. Only a full Cmd+Q restart of the desktop app
temporarily clears it for the first navigation. Please prioritize — this blocks
all browser-verification workflows.

Still reproducing on 2026-06-23, Windows — Claude in Chrome extension v1.0.77, Claude Code CLI 2.1.187.

It's now two releases (v1.0.76, v1.0.77) since I posted the source-level root cause in this comment: de-minifying the shipped bundle showed the deny comes from an exclusive per-turn allowlist in the permission check. That logic appears unchanged in v1.0.77 — same single-origin lock, same needsPrompt: false hard-deny for every domain after the first.

Today's repro signature (fresh MCP session, Windows):

• First domain navigated (wta.org) → succeeds; repeat navigations within it keep working.
• Every other domain is then rejected with Navigation to this domain is not allowed: example.com, google.com, parks.wa.gov, rei.com, wikipedia.org, alltrails.com, recreation.gov.
• Not the extension Site-access setting — confirmed "On all sites."
• Not a per-site policy — generic domains (example.com, google.com) are blocked too.
• Opening a brand-new tab and trying a fresh domain first → still rejected, so the lock is session-level, not tab-level.

Net effect: the browser MCP is unusable for any multi-site workflow. The mechanism is known and documented in this thread at the code level (independently confirmed by @zoyth and @chiptuned), and it's still shipping. This has been open since April 3 — can it get prioritized?

Confirmed workaround (Windows 11, desktop app, extension current as of 2026-07-09):

Consistent with the de-minified analysis above (exclusive per-turn allowlist), the behavior we measured is: whichever domain the session touches first becomes the only allowed domain — every later domain is hard-denied with no approval prompt.

So the workaround is simply: make your target site the very first navigation of a fresh session.

Evidence from one machine, same Chrome profile, same MCP tools:

• Fresh desktop-app session, first navigate = example.com → afterwards x.com / mail.google.com are denied forever ("Navigation to this domain is not allowed", no prompt).
• Fresh desktop-app session, first navigate = x.com → works fully (navigate, screenshot, javascript_tool on a logged-in session).
• Scheduled/headless sessions that start directly on x.com have always worked — which had made the failures look session-type-specific until we traced it to first-domain locking.
• CLI sessions show domain approval prompts and can approve multiple domains; the desktop app never renders a prompt.

Limitation: one domain per session — multi-domain workflows still need the CLI or separate sessions. Hope this helps others until the turnApprovedDomains clearing logic gets fixed.

Counter-datapoint (macOS, desktop app, extension 1.0.80): neither the block nor the first-domain lock reproduced — two fresh sessions, same day, both orderings.

Original reporter here (filed 2026-04-03 at v1.0.66, all tools failing on all domains). Retested today in fresh Claude Code desktop-app sessions, same machine/profile:

• Session A (target-first): first navigation = outlook.cloud.microsoft (authenticated M365) → navigate, read_page, javascript_tool, find all worked; example.com later in the same session also worked (the lock predicts it denied).
• Session B (neutral-first): example.com → en.wikipedia.org → outlook.cloud.microsoft (authenticated) → www.iana.org (via in-page link click) — four domains, one session, every tool worked on every domain (navigate, read_page, javascript_tool, find, screenshot). No "Navigation to this domain is not allowed," no "Permission denied," and no approval prompt ever rendered.

Environment: Claude in Chrome 1.0.80, Chrome 150.0.0.0, Claude Code 2.1.154 (desktop app), macOS.

Given the 2026-07-09 comment above reproduced first-domain locking on Windows desktop with a then-current extension, this looks either fixed in a recent extension build or platform/config-dependent. If a maintainer can say whether the turnApprovedDomains clearing logic changed between that build and 1.0.80, that would settle which.

Same regression on Windows 11 + Claude Code Desktop app (re-verified 2026-07-17; first hit this on 2026-07-08).

Setup: Claude in Chrome extension connected and healthy (list_connected_browsers and tabs_context_mcp work, MCP tab group is created fine). Chrome-level site access for the extension is set to "On all sites". Browser restart, extension toggle off/on, and Desktop reinstall do not help.

Symptoms:

• navigate to any unapproved domain fails instantly with Navigation to this domain is not allowed (tested wikipedia.org, anthropic.com). No approval dialog ever renders — not in Chrome, not in the desktop app.
• The extension panel "Your approved sites" shows "No sites have been approved yet" and offers no way to add a site manually, so the allowlist can never be populated from a Claude Code session.
• example.com is fully usable (navigate, click, screenshot, javascript_tool) despite the empty approved list — looks hardcoded. Note: on 2026-07-08 even example.com was denied; as of 2026-07-17 it works while everything else is still blocked.

Data points that may help localize the bug:

1. Clicking an <a> link on an approved page successfully navigates the tab to an unapproved domain (example.com → iana.org via computer left_click), while a direct navigate call to that same domain is blocked. On the unapproved domain, read-only tools (get_page_text, read_page) keep working; click/key/screenshot/JS return Permission denied for this action on this domain. This matches the earlier diagnosis that the block fires in the MCP wrapper above the extension's approval layer, not in the extension's page-level permission logic.
2. The very first navigate issued in a fresh chrome://newtab tab hangs until the 300 s MCP timeout even though the navigation actually completes (the tab loads, confirmed via tabs_context_mcp); subsequent navigate calls return instantly.

From claude.ai (Cowork) sessions the site-approval card renders and browsing works, so this is specific to the Claude Code ↔ extension path. Can provide more details/logs if useful.

Adding a data point — same bug, still unresolved:

• Extension: Claude in Chrome v1.0.85 (macOS)
• Symptom: navigate returns "Navigation to this domain is not allowed"

for every domain tested — wikipedia.org, semrush.com, spyfu.com, and
even claude.ai itself.

• Site access is correctly set to "On all sites" in chrome://extensions.
• It was working earlier in the same session (successfully navigated to

google.com and tiktok.com), then started failing mid-session with no
action on my part.

• Troubleshooting already tried, no effect on any of them:
• Toggled the extension off/on in chrome://extensions
• Checked for updates via the Update button (Developer mode on) —

already on latest

• Fully quit Chrome (Cmd+Q) and relaunched

Note: #66074, which had similar detail, was just closed as a duplicate
of this one — pointing anyone else who lands there back to this thread.
Happy to provide more diagnostics if useful.