Claude in Chrome MCP bridge refuses localhost/127.0.0.1 navigation while side-panel Claude allows it

Update with a corrected diagnosis after more testing: this is not specific to local addresses.

From the same session, same connected browser:

• https://app.navattic.com → ✅ navigates
• http://localhost:3000 → ❌ "Navigation to this domain is not allowed"
• http://127.0.0.1:3000 → ❌ same
• https://navattic.ngrok.app (reserved tunnel domain) → ❌ same
• https://example.com → ❌ same

So the MCP bridge appears to enforce a domain allowlist (presumably the organization's browsing policy), refusing everything else. The side-panel Claude in the same browser is not subject to it, which is what made this look like a localhost-only rule at first.

Remaining asks, refined:

1. The error should say why — "Navigation to this domain is not allowed by your organization's browsing policy" (if that's the mechanism) would have saved a day of debugging permissions and reinstalling the extension. As-is there is no prompt, no policy reference, and the extension's approved-sites UI stays empty.
2. Documentation of where this policy is configured and whether localhost can be allowed for local development workflows — driving a local dev server is a core Claude Code use case.

Final diagnosis after exhausting every local remediation — this now looks like a policy-sync bug, not a policy choice:

Account configuration (claude.ai → Settings → Claude in Chrome):

• "Default for all sites: Allow all sites" — UI confirms "Claude works everywhere except sites you block below"
• Blocked sites: empty ("No sites added yet")
• The settings page states these permissions "apply to Claude in Chrome and the in-app Browser in Claude Code Desktop"

Observed enforcement on the MCP bridge (Claude Code Desktop → Chrome extension):

• Exactly one host navigates: https://app.navattic.com
• Refused, instantly, with no approval prompt anywhere (side panel open and watched, toolbar, notifications): www.navattic.com, localhost:3000, 127.0.0.1:3000, https://example.com, an ngrok domain
• The instant rejection suggests no approval round-trip is attempted at all

Remediations exhausted, no change:

• Fresh reinstall of the extension from the Web Store
• Full Chrome restart
• Full Claude Desktop app restart (in case the bridge snapshots permissions at startup)
• Verified chrome://extensions site access = "On all sites"

Meanwhile the side-panel Claude in the same browser drives localhost:3000 without issue, confirming the extension itself has no such restriction.

Summary: account settings say allow-all; the remote bridge enforces a one-host allowlist (a host that appears to be a stale grant surviving reinstall, i.e. stored account-side) and the approval flow for new sites is unreachable. Happy to provide session IDs / timestamps privately if useful.

More findings from experimenting with claude.ai → Settings → Claude in Chrome ("Site permissions", stated to apply to Claude in Chrome and the in-app Browser in Claude Code Desktop):

Two enforcement layers with distinct error strings. Switching "Default for all sites" to Block all sites changed the error for app.navattic.com from Navigation to this domain is not allowed to This site is blocked by your site permissions. — while localhost / www.navattic.com kept the original generic error. So the user-level site-permissions setting is one layer (its default toggle applies ~instantly), and something above it — invisible on this settings page, allowlisting exactly one host — produces the generic error. If that upper layer is an org-level policy, error string and docs should say so.

Allowed-sites entries not honored in block mode. With default = Block all sites and an explicit allowlist containing app.navattic.com (exact host), navigation to https://app.navattic.com still fails with "This site is blocked by your site permissions." The default toggle propagates, the entries apparently don't (tested repeatedly over several minutes).

Port is stripped from entries. Typing localhost:3000 into "Add websites" saves as localhost — fine if matching is host-only, but combined with the above we couldn't verify any entry matching at all.

Subdomain matching: a navattic.com entry does not cover app.navattic.com (exact-host matching) — worth documenting either way.

Net effect: block-by-default mode currently breaks previously-working hosts and the allowlist can't restore them — user had to revert to "Allow all sites".

Last datapoint for triage: this is a personal claude.ai account — no organization — and we confirmed the Desktop app, the extension side panel, and the settings page are all signed into that same account. So the upper enforcement layer (the generic "Navigation to this domain is not allowed", allowlisting exactly one host) is not an org policy: it's account-level server-side state that no user-visible setting controls, and the per-site approval flow that would presumably extend it never triggers.

Timeline note that may help: the one allowed host (app.navattic.com) very likely received a grant through an earlier working approval flow months ago; it survived a full extension reinstall. Everything requested since gets the silent refusal.

Current user-facing state: reverted to "Allow all sites" (which restores nothing beyond the one grandfathered host, but block-mode was strictly worse — see previous comment).

Two updates — one correction to my earlier comment, and a finding that rules out the last configuration explanation.

Correction. I previously wrote that allowed-sites entries were "not honored" in block mode. That was wrong: after adding app.navattic.com explicitly, it did start working — the entries propagate, just not immediately (minutes, not seconds). Please disregard that part; the slow propagation is a minor UX note, not the bug.

The org account also says "Allow all sites". The user is a member of a Claude team org (company email). Its admin shared the org-level Claude in Chrome settings: "Enable for your team" on (Default), "Default for all sites: Allow all sites", blocked sites empty. So both the personal account and the org are configured allow-all, yet the remote bridge still refuses nearly everything.

Two distinct enforcement layers, distinguishable by error string:

| Layer | Error string | Configurable? |
|---|---|---|
| Site permissions (personal and/or org) | This site is blocked by your site permissions. | Yes — entries work, propagate in minutes |
| Unknown upper layer | Navigation to this domain is not allowed | No visible control; unaffected by either account's allow-all |

The upper layer's allowlist is exactly one host: app.navattic.com. Everything else — app.navattic.dev, www.navattic.com, localhost, 127.0.0.1, example.com, a reserved ngrok domain — gets the generic error, even when explicitly present in site permissions (localhost was in the allowed list and still produced the generic error).

The two layers evaluate in order, which is worth knowing when reading these errors: site permissions first (its own error string), then the upper layer. app.navattic.dev initially looked allowed only because block-mode was shadowing it; once site permissions allowed it, the upper layer refused it with the generic error.

That single allowed host is also where this user's Navattic MCP connector endpoint lives (app.navattic.com/api/mcp), and it survived a full extension reinstall — so if installed connectors implicitly grant browsing rights to their origin, that would explain the set of one. Worth documenting either way, since it is invisible to users and unaffected by the settings page that claims to govern these permissions.

Ask stands: make the upper layer visible and configurable (or explain it in the error), and let local development hosts be allowed.