[BUG] Claude in Chrome: navigation refused for domains present in "Your approved sites"

Summary

mcp__claude-in-chrome__navigate refuses with "Navigation to this domain is not allowed" for domains that are explicitly present in the extension's own "Your approved sites" list — while a different domain on that same list navigates successfully in the same tab, seconds apart.

Environment

• Claude Code 2.1.226
• Google Chrome 153.0.8010.53
• macOS 26.6.2
• Driving Claude in Chrome from a Claude Code session via the mcp__claude-in-chrome__* tools

Reproduction

Three domains, all three present in "Your approved sites" (each shown with a Revoke button and a "Last used" timestamp), navigated in the same tab within the same minute:

| Domain | On approved list | navigate result |
| --- | --- | --- |
| A.atlassian.net | yes | ✅ navigated |
| B.com (private dev env) | yes | ❌ "Navigation to this domain is not allowed" |
| app.C.com (private dev env) | yes | ❌ "Navigation to this domain is not allowed" |
| www.B.com | no | ❌ same error |

Domain names for B and C are redacted because they are private infrastructure; happy to supply them to Anthropic directly if it helps reproduction. The salient point is that B and C are on the approved list and are refused, while A is on the same list and works.

What I ruled out

• Not a general Chrome-automation failure. A.atlassian.net navigated on the first attempt, in the same tab, immediately before and after the failures.
• Not DNS or reachability. All hostnames under B.com resolve to a legitimate AWS ELB. One apex A-record IP looked foreign but whois confirms it is Amazon-owned (AMAZO-4). The site serves HTTP 200 to curl from the same machine.
• Not domain reputation. These are ordinary company-owned domains serving a normal web app.
• The check appears to precede DNS resolution. app.C.com does not resolve at all in public DNS, yet returns the same "Navigation to this domain is not allowed" message rather than a resolution/network error. That points at an allowlist/denylist decision made before any lookup — so whatever list is consulted is not the one rendered in "Your approved sites".

Why I think this is a defect rather than configuration

I specifically checked whether an organization-level browsing policy might legitimately override per-site user approvals, since that would make this correct behaviour rather than a bug. Per the public documentation:

• Claude in Chrome site permissions are described as inherited from the Chrome extension's settings.
• The documented org control is deniedMcpServers, which disables the claude-in-chrome MCP server entirely — it does not provide selective per-domain blocking.
• sandbox.network.allowedDomains / deniedDomains apply to the Bash tool's network isolation, not to Chrome navigation.

So there is no documented mechanism by which an approved site should be selectively refused. If such a layer does exist and is simply undocumented, the actionable bug is then that the refusal message and the settings UI disagree with it: the UI shows the domain as approved with a recent "Last used" timestamp, and the error gives no indication that a different policy made the decision.

Impact

The failure is indistinguishable from a user-permission problem, which sends you to the settings page — where the domain is already listed as approved. There is no signal pointing anywhere else, so it is very easy to lose a lot of time here.

Suggested fix

Either honour the approved-sites entries, or make the refusal say which layer rejected the navigation and where that is configured.