[BUG] Claude in Chrome navigate tool blocked for all non-claude.ai domains since v2.1.111

[tubame0208]

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?

Bug Report

Summary

Since Claude Code v2.1.111, the mcp__Claude_in_Chrome__navigate tool returns
"Navigation to this domain is not allowed" for all domains except claude.ai.
This worked correctly in v2.1.92.

Steps to Reproduce

1. Use Claude Code v2.1.111 with Claude in Chrome extension
2. Ask Claude to navigate to any external site (e.g. aistudio.google.com,
   github.com, ideogram.ai)
3. Observe: "Navigation to this domain is not allowed" error

Expected Behavior

Claude in Chrome should be able to navigate to external sites,
or at minimum provide a way to configure an allowed domain list.

Actual Behavior

All navigation to non-claude.ai domains is blocked with:
Navigation to this domain is not allowed

Environment

• Claude Code: v2.1.111
• OS: macOS
• Chrome Extension: Claude v1.0.68

Additional Context

• v2.1.92 (still installed locally) works correctly
• The restriction appears to come from permissionMode
  passed by Claude Code to the extension's mcpPermissions module
• The claude.ai/settings/browser-extension page was set to
  "Allow extension on all sites" but did not resolve the issue

Request

Please either restore the previous behavior or add a setting in
settings.local.json to configure allowed domains for Claude in Chrome navigation.

What Should Happen?

Claude in Chromeが、claude.ai以外の外部サイト（例：aistudio.google.com）にも
ナビゲートできるべきです。または、settings.local.json などで許可ドメインを
ユーザーが設定できる仕組みが提供されるべきです。
v2.1.92では正常に動作していました。

Error Messages/Logs

Navigation to this domain is not allowed

Steps to Reproduce

1. Claude Code v2.1.111 + Claude in Chrome拡張機能を使用
2. Claudeに「aistudio.google.comを開いて」と指示
3. mcp__Claude_in_Chrome__navigateツールが呼び出される
4. "Navigation to this domain is not allowed" エラーが返る
   ※ v2.1.92では同じ操作が正常に動作する

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.111

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Claude in Chrome MCP tools: "Navigation to this domain is not allowed" on all domains (v1.0.66) #43255
2. [BUG] Claude for Chrome MCP tools return "Navigation to this domain is not allowed" for ALL domains (v1.0.66+ regression) #50606
3. [BUG] Claude in Chrome MCP: navigate and read_page denied on ALL domains from Claude Desktop (Windows 11) — no approval popup renders #49979

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[0xbrainkid]

This is a sharp access-boundary regression because the allowed browsing surface appears to have collapsed from "external web" to effectively "claude.ai only." If that change was intentional, it is drastically under-communicated. If it was accidental, it is a major MCP capability regression.

The important historical detail is the version comparison. Since the same workflow reportedly worked in v2.1.92 and broke in v2.1.111+, the issue is not generic user misunderstanding of tool scope. It points to a changed domain-allowlist or enforcement path.

From the user perspective, this makes the browser tool feel broken for most real tasks, because web automation/navigation is valuable precisely on non-Claude domains. A browser connector that cannot leave the vendor domain is functionally close to no browser connector at all.

[bsconnect-nl]

Confirming this regression on Claude Desktop v2.1.121 (Windows 11). Adding a
specific data point that doesn't appear in other reports yet: in my case,
the navigate-block correlates with the working-directory's project name.
Two parallel Claude Desktop sessions on the same machine, same Chrome (with
"Claude in Chrome" extension), same user account:

Session cwd	client.nl	admin.test
C:\laragon\www\client	blocked	works
C:\laragon\www\admin\core\backend\engines...	works	blocked
Both sessions report "Navigation to this domain is not allowed" with no
approval prompt firing. "Your approved sites" in the extension settings
stays empty in both.
Each session can navigate to the OTHER project's domain but not its own.
steenhuis.nl, example.com, github.com etc. work fine in both. Tested with
both connected browsers (select_browser + switch_browser confirmed), fresh
tab groups — pattern is consistent.
ngrok-free.dev URLs also hard-blocked, so tunnel-based workarounds aren't
viable either.
CLI v2.1.110 (the version right before this regression) installed via npm
does not ship the Claude-in-Chrome MCP server, so a CLI-side downgrade
test is not possible without manual MCP wiring.
Workarounds I've tried that don't help:

• Toggle/reinstall extension
• Disable other extensions
• switch_browser to confirmed-correct Chrome instance
• Fresh tabs in fresh tab-groups
• Browser permissions are "Op alle sites" / On all sites

[localden]

Thank you for your report — we are currently in the process of triaging MCP-related issues and this one appears to describe the same problem as #43255. To keep the discussion and any fix in one place, we're consolidating into that issue and closing this one. If you have logs, repro steps, or environment details that aren't already covered in #43255, please add them there — it'll help us track this down faster.

[kyandiwp-hub]

+1, still happening on Claude Code v2.1.128 (Claude in Chrome extension v1.0.69) as of 2026-05-06.

The mcp__Claude_in_Chrome__navigate tool returns "Navigation to this domain is not allowed" for major affiliate marketing platforms (which were working fine before v2.1.111):

• pub.a8.net: blocked
• a8.net: blocked
• af.moshimo.com: blocked
• afi-b.com: blocked
• accesstrade.net: works (only one I tested that passes)

Confirmed not a client-side issue:

• Extension "Site access" is set to "All sites"
• Toggling extension off/on does not help
• Full Chrome restart does not help

These are legitimate business automation use cases (managing my own affiliate links for my blog at kyandilife.com). Please prioritize fixing the server-side org_policy classifier — currently the only workaround is full manual operation.

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.