claude-code - 💡(How to fix) Fix mcp__Claude_in_Chrome__navigate silently denies non-pre-approved domains — no user-facing approval path exists anywhere [2 comments, 3 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When Claude Code Desktop's mcp__Claude_in_Chrome__navigate tool is called with a domain not in the session's seeded turnApprovedDomains set, the extension silently denies the request with { allowed: false, needsPrompt: false }. No approval prompt surfaces anywhere in the product. No toast, no side-panel control, no UI of any kind.

This breaks any workflow involving per-branch preview URLs (Vercel, Netlify, Cloudflare Pages, Render, etc.) where the target hostname is unique per PR and cannot be known at session start.

The UI scaffolding for the fix already exists at claude.ai/settings/browser-extension — Anthropic has shipped the block-list half of the permission model (blockedUrlPatterns) but not the allow-list half (which would be the UI counterpart to the extension's existing turnApprovedDomains / permissionStorage).

What Should Happen?

One or more of the following:

1. An allow-list UI at claude.ai/settings/browser-extension symmetric to the existing block-list, with wildcard support (*.vercel.app, *.netlify.app, *.pages.dev, *.onrender.com).
2. 1. Gate 1 should fall through to { needsPrompt: true } in interactive sessions instead of { allowed: false, needsPrompt: false } — so the user at least gets a visible approval dialog.
3. 1. An MCP tool the agent can call to request additional domains mid-session, triggering a user-confirmation prompt in Claude Code Desktop.
4. 1. An allow-list key in the extension's managed_schema.json alongside blockedUrlPatterns.

Error Messages/Logs

Tool call response from mcp__Claude_in_Chrome__navigate:
"Navigation to this domain is not allowed"

No stack trace. No additional detail. The error is returned synchronously with no user-facing prompt or notification of any kind.

Steps to Reproduce

1. Open Claude Code Desktop (v1.2773.0.0, Windows 11 MSIX) with the Claude in Chrome integration active (extension v1.0.68).
2. Start a new conversation. Ask Claude to navigate to a Vercel PR preview URL, e.g.: "Go to https://tenefly-bicjcd639-mensahb89s-projects.vercel.app and tell me what you see."
3. 1. Claude Code Desktop activates follow_a_plan permission mode and seeds turnApprovedDomains with the project's known domains (e.g., ["www.tenefly.com"]) via IPC: { subtype: "set_permission_mode", mode: "follow_a_plan", allowed_domains: ["www.tenefly.com"] }.
4. 1. Claude calls mcp__Claude_in_Chrome__navigate with the preview URL.
5. 1. Result: Tool returns "Navigation to this domain is not allowed". No prompt appears anywhere — not in Claude Code Desktop, not in the Chrome extension popup, not as a toast or notification. Root cause (traced to extension source):

In fcoeoabgfenejglbffodgkkbkcdhcgfn/1.0.68_0/assets/PermissionManager-WI3FAKQw.js, checkPermission() runs:

// Gate 1 — fires before persistent storage and before the prompt fallback
if (r && this.turnApprovedDomains.size > 0 && !this.isTurnApprovedDomain(r))
  return { allowed: false, needsPrompt: false };

When turnApprovedDomains is non-empty, this gate hard-denies any unlisted domain with needsPrompt: false, bypassing both the persistent permissionStorage lookup and the user-approval prompt fallback.

Every path verified as non-working:

• Editing CLAUDE.md "Browser access" section — not consulted by host plan seeding
• • Brand-new session with preview URL in the first user message — hostname still not in turnApprovedDomains
• • • Clicking the Claude in Chrome extension icon — no per-domain approval UI in v1.0.68
• • • • Chrome managed policy (managed_schema.json) — exposes only blockedUrlPatterns and forceLoginOrgUUID; no allow-list key
• • • • • claude.ai/settings/browser-extension — full audit performed; exposes only a block-list (binary on/off + blocked sites list). "Default for all sites" dropdown has exactly two options: "Allow extension" and "Block extension". No allow-list, no wildcard field
• • • • • • Claude Code Desktop CLI (claude --help) — only --chrome/--no-chrome
• • • • • • • All Claude Code Desktop config files — no browser-domain settings
• • • • • • • • Editing the extension's permissionStorage LevelDB — irrelevant because Gate 1 fires before that store is consulted
• • • • • • • • • /org/settings on claude.ai — redirects to homepage (individual Pro account); no org admin console

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

1.2773.0.0 (Claude Code Desktop, Windows MSIX). Claude in Chrome extension v1.0.68.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Why this hurts

Per-PR preview deployments are table stakes for modern web dev. Our team ships UI changes behind feature flags and needs to visually verify on a Vercel preview URL before merge. Preview hostnames are unique per branch — there is no way to pre-list them at session start.

Viable workarounds attempted:

• Patching the extension file locally — Chrome hashes extension files and can silently reinstall from cache or flag the extension as corrupted (disabling the whole integration). Not viable.
• • DevTools monkey-patching the running service worker — MV3 service workers idle-kill after ~30 seconds; the patch is lost on restart. Not viable for tasks longer than a few minutes.
• • • Merging without preview verification — defeats the verification gate entirely.

Why the fix is low-effort

The backend already fully exists:

• turnApprovedDomains (in-memory Set) and permissionStorage (LevelDB) are already implemented in the extension
• • The set_permission_mode IPC path already accepts an allowed_domains array
• • • claude.ai/settings/browser-extension already has the UI scaffold (block-list side) Shipping the allow-list side is finishing what's half-built, not net-new infrastructure. Adding wildcard support (*.vercel.app) would unblock all PR preview workflows with a single entry.

Suggested fix preference order

1. Add allow-list UI to claude.ai/settings/browser-extension with wildcard support — symmetric to the existing block-list
2. 1. Change Gate 1 from { allowed: false, needsPrompt: false } to { allowed: false, needsPrompt: true } in interactive sessions — at minimum gives the user a visible approval path
3. 1. Expose an MCP tool for the agent to request additional domains mid-session with user confirmation
4. 1. Add an allow-list key to managed_schema.json alongside blockedUrlPatterns Happy to test patches on a preview build and provide additional repro data.