[BUG] Claude in Chrome MCP tools: "Navigation to this domain is not allowed" on ALL domains — Desktop App users have no working workaround (v1.0.66+ regression)

Resolved 💬 4 comments Opened Jun 7, 2026 by altheg Closed Jun 11, 2026

Preflight Checklist

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

What's Wrong?

All Claude-in-Chrome MCP browser tools (navigate, get_page_text, read_page, find, screenshot) return "Navigation to this domain is not allowed" or "Permission denied for reading page content" on every real domain. No approval dialog ever appears, so there is no way to manually grant permissions.
Affected tools: mcp__Claude_in_Chrome__navigate, get_page_text, read_page, find, computer (screenshot)
Affected domains: all real domains (google.com, drive.google.com, livello.com, hostinger.com, wikipedia.org — tested exhaustively)
Cowork browser tools work fine on the same domains.
Additionally: the known workaround from #55209 (disabling the Desktop native messaging manifest so Claude Code CLI takes over) does NOT work for Desktop App users. There is only one NMH (com.anthropic.claude_browser_extension.json) pointing to Claude.app — no separate Claude Code socket exists unless running claude --chrome via terminal. After disabling the manifest, the extension finds no host at all and everything breaks including Cowork.

What Should Happen?

MCP browser tools should be able to navigate to and read content from any domain, either automatically (if "all sites" is granted) or after showing an approval dialog for new domains. The permission check should happen at the extension level, not block in the MCP wrapper before the approval flow can run.

Error Messages/Logs

Navigation to this domain is not allowed
Permission denied for reading page content on this domain

Steps to Reproduce

  1. Install Claude Desktop App (v1.9659.2) with Claude Code (v2.1.156) on macOS
  2. Install Claude-for-Chrome extension (v1.0.70–1.0.75) — set to "all sites" permission
  3. Connect Claude Code to Chrome via MCP (mcp__Claude_in_Chrome__)
  4. Call navigate with any real URL, e.g. https://google.com
  5. → Immediately returns "Navigation to this domain is not allowed" — no dialog appears
  6. Note: example.com works, all other domains fail
  7. Attempted workaround: rename com.anthropic.claude_browser_extension.json to .disabled + toggle extension → breaks completely, no fallback NMH exists for Desktop App users

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.0.65

Claude Code Version

2.1.156

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Root cause (self-diagnosed, confirmed against existing issues):
The permission block fires in the MCP wrapper BEFORE the extension's site-approval logic runs — so approvedSites stays permanently empty regardless of Chrome extension settings.
Verified NOT the cause:

  • Chrome extension host permissions: <all_urls> granted in all 43 profiles ✓
  • Claude Code settings.json: no domain restrictions, no deny rules ✓
  • Restarting Chrome or Claude: no effect ✓
  • Multiple Chrome instances/profiles: all tested, all fail ✓

Related issues: #43255 (open), #50606 (closed as duplicate — problem persists), #55209 (workaround only for CLI users, not Desktop App users)
Request:

  1. Fix the MCP wrapper regression (permission check must happen after, not before the approval dialog)
  2. Give Claude Code its own NMH independent of Claude.app so Desktop App users can use the #55209 workaround
  3. Or: add an "allow all domains" flag in settings.json as a stopgap

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗