[BUG] Claude Desktop "Claude in Chrome" allowlist not respected — MCP navigate returns permission_required for whitelisted domains
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?
Bug Description
The "Claude in Chrome" connector in Claude Desktop reports the extension as connected and successfully loads all MCP tools, but every navigate call from the Desktop app fails with permission_required — even when the target domain is explicitly listed under Settings → Claude in Chrome → Erlaubte Seiten (Allowed Sites) and "Standard für alle Websites" is set to "Erweiterung blockieren".
The same domains work without issue when used directly from the Chrome extension sidepanel — only the Desktop app's MCP navigation is blocked. This indicates the allowlist managed by the Desktop app's settings UI is not being honored by the MCP browser tool layer.
This is not the dual-install / native-host conflict from #20887 or #54567 — Claude Code CLI is not installed on this machine and only one Anthropic native host is registered (see Environment).
Environment
- OS: Windows 11
- Claude Desktop: 1.6608.0 (installed 2026-05-08, latest auto-update)
- Claude Code CLI: Not installed (
Get-Command claudereturns nothing; not in PATH) - Chrome: latest version 08.05.2026
- Claude in Chrome extension: latest version 08.05.2026
- Plan: Max
- Two Chrome browsers connected to the same account (selected one called "Arbeits Laptop" via
switch_browser) - Native messaging hosts registered (verified via PowerShell):
Get-ChildItem "HKCU:\Software\Google\Chrome\NativeMessagingHosts" |
Where-Object { $_.PSChildName -like "*anthropic*" }
Returns only:
com.anthropic.claude_browser_extension
→ No conflicting native host. Single, clean install.
Steps to Reproduce
- Install Claude Desktop 1.6608.0 on Windows 11.
- Install the "Claude in Chrome" extension and sign in with the same account.
- In Claude Desktop, go to Settings → Konnektoren and enable "Claude in Chrome".
- Go to Settings → Claude in Chrome (under the Desktop-App section).
- Set "Standard für alle Websites" to "Erweiterung blockieren" (block by default).
- Click "Websites hinzufügen" and add a domain (e.g.
vespa-suedpfalz.de). Confirm the toast "Erlaubte Websites aktualisiert" appears and the domain shows up in the "Erlaubte Seiten" list. - Open a Claude Desktop chat. The Chrome MCP tools (
tabs_context_mcp,navigate,computer, etc.) load successfully. - Call
tabs_context_mcpwithcreateIfEmpty: true→ succeeds, returns a validtabId. - Call
navigatewith thattabIdandurl: "https://vespa-suedpfalz.de"(a whitelisted domain).
Expected Behavior
navigate should succeed because the domain is on the allowlist. The browser should load the page and subsequent screenshot calls should work.
Actual Behavior
actions[0] (navigate) failed: permission_required: vespa-suedpfalz.de (0 completed, N remaining)
The same error is returned for every domain on the allowlist, including:vespa-suedpfalz.de, qn.1qn.de, quadronet.de, derfotorabe.de, webshop.1qn.de, weinshop.1qn.de, kimmle-wein.de, oel-sparen.de.
No permission prompt appears anywhere (not in the sidepanel, not as a Chrome dialog, not as a Desktop toast) when navigate is called. The request is silently blocked at the MCP permission layer.
What Already Works
- ✅ Sidepanel chat in the Chrome extension navigates and screenshots the same domains without any issue
- ✅ MCP tools load successfully in the Desktop app (
tabs_context_mcp,navigate,computer,browser_batch,javascript_tool,get_page_text, etc.) - ✅ Browser selection via
switch_browserworks (paired with "Arbeits Laptop") - ✅ Tab group creation works (
tabs_context_mcpwithcreateIfEmpty: truereturns a fresh tab in a new group) - ✅ Other MCP servers (filesystem, web_fetch, web_search) work normally from the same Desktop chat
What I Already Tried
- ✅ Toggled the "Claude in Chrome" connector off and on in Settings → Konnektoren
- ✅ Fully restarted Claude Desktop (Tray → Quit → relaunch — not just window close)
- ✅ Fully restarted Chrome
- ✅ Verified the allowlist still contains the domains after restart
- ✅ Verified the same Google account is signed in everywhere (Chrome, extension, Desktop app)
- ✅ Tried navigating from a freshly created MCP tab group (multiple
tabGroupIds tried) - ✅ Tried different domains from the allowlist — all return the same error
- ✅ Verified only one Anthropic native host is registered in the Windows Registry (no conflicts)
- ❌ No permission prompt ever appears that could grant access manually
Hypothesis
The allowlist stored / persisted from the Claude Desktop Settings → Claude in Chrome → Erlaubte Seiten UI is either:
- Written to a location the MCP browser tool's permission check does not read from, or
- Read at startup but not re-evaluated after edits, or
- Scoped only to the in-extension sidepanel session, not the Desktop-driven MCP layer.
A separate per-domain runtime permission prompt is also never triggered, leaving no way to grant access at all from the Desktop app side. The user is effectively locked out of navigate for all domains — the allowlist UI exists but has no functional effect on MCP calls.
Workaround
Currently the only working browser automation path on this setup is to start a new conversation in the Chrome extension sidepanel instead of the Desktop app. This defeats the purpose of having the connector exposed in Desktop.
Related Issues
- #20887 — Native messaging host conflict between Desktop and Code (not applicable here, Code is not installed)
- #54567 — Silent failure when both Desktop and CLI native-messaging hosts are registered (not applicable, single host registered)
- #53472 — Extension connects to cloud bridge but never to local CLI on Windows
- #15336 — Native Messaging Host not installing on Windows
- #23218 — Claude in Chrome extension not connecting on Windows 11
These all involve a Windows-specific class of native-messaging / permission-sync issues. This issue appears to be a distinct manifestation: native messaging itself works (tools load, tab group is created), but the Desktop app's allowlist never reaches the permission gate that decides whether navigate is allowed.
Suggested Investigation
- Check whether
navigatereads its allowlist from the same store the Settings → Claude in Chrome → Erlaubte Seiten UI writes to. - Add a console log in the MCP permission gate showing the loaded allowlist on each
navigatecall so users can debug. - Surface a permission prompt (in the sidepanel or as a Chrome notification) when
navigatehits a domain not in the allowlist, instead of silently returningpermission_required.
The "Claude in Chrome" connector in Claude Desktop reports the extension as connected and successfully loads all MCP tools, but every navigate call from the Desktop app fails with permission_required — even when the target domain is explicitly listed under Settings → Claude in Chrome → Erlaubte Seiten (Allowed Sites) and "Standard für alle Websites" is set to "Erweiterung blockieren".
The same domains work without issue when used directly from the Chrome extension sidepanel — only the Desktop app's MCP navigation is blocked. This indicates the allowlist managed by the Desktop app's settings UI is not being honored by the MCP browser tool layer.
This is not the dual-install / native-host conflict from #20887 or #54567 — Claude Code CLI is not installed on this machine and only one Anthropic native host is registered (see Environment).
Environment
- OS: Windows 11
- Claude Desktop: 1.6608.0 (installed 2026-05-08, latest auto-update)
- Claude Code CLI: Not installed (
Get-Command claudereturns nothing; not in PATH) - Chrome: latest version 08.05.2026
- Claude in Chrome extension: latest version 08.05.2026
- Plan: Max
- Two Chrome browsers connected to the same account (selected one called "Arbeits Laptop" via
switch_browser) - Native messaging hosts registered (verified via PowerShell):
Get-ChildItem "HKCU:\Software\Google\Chrome\NativeMessagingHosts" |
Where-Object { $_.PSChildName -like "*anthropic*" }
Returns only:
com.anthropic.claude_browser_extension
→ No conflicting native host. Single, clean install.
What Should Happen?
When a domain is added to the "Erlaubte Seiten" (Allowed Sites) list under
Settings → Claude in Chrome in the Claude Desktop app, MCP navigate calls
to that domain from a Desktop chat should succeed without being blocked by
the permission layer.
Specifically, calling:
navigate({ tabId: <validTabId>, url: "https://vespa-suedpfalz.de" })
with vespa-suedpfalz.de already in the allowlist should:
- Load the URL in the MCP-managed tab
- Allow subsequent
screenshot,get_page_text,javascript_tool, etc.
calls on that tab
- NOT return
permission_required
Equivalently — if the allowlist is intentionally not the source of truth for
MCP navigate permissions, then a permission prompt should appear (in the
sidepanel, as a Chrome notification, or as a Desktop dialog) the first time
a new domain is requested, allowing the user to approve it. Currently neither
happens: the allowlist has no effect AND no prompt fires, leaving the user
with no working path to grant access.
Error Messages/Logs
=== Error from MCP navigate call ===
actions[0] (navigate) failed: permission_required: vespa-suedpfalz.de (0 completed, 2 remaining)
Same error returned for every whitelisted domain (vespa-suedpfalz.de, qn.1qn.de,
quadronet.de, derfotorabe.de, webshop.1qn.de, weinshop.1qn.de, kimmle-wein.de,
oel-sparen.de). No accompanying log entry, no stack trace, no permission prompt —
the call is rejected silently at the permission gate.
=== Registry verification (PowerShell) ===
PS C:\Users\email> Get-ChildItem "HKCU:\Software\Google\Chrome\NativeMessagingHosts" `
-ErrorAction SilentlyContinue |
Where-Object { $_.PSChildName -like "*anthropic*" } |
Select-Object PSChildName
PSChildName
-----------
com.anthropic.claude_browser_extension
=== Claude Code CLI presence check ===
PS C:\Users\email> Get-Command claude -ErrorAction SilentlyContinue
(no output — claude CLI is not installed)
=== MCP tool calls that DO succeed in the same session ===
tabs_context_mcp (createIfEmpty: true)
→ returns: { availableTabs: [{ tabId: 1755836573, ... }], tabGroupId: 805315085 }
switch_browser
→ returns: "Connected to browser 'Arbeits Laptop'."
(Browser pairing and tab group creation work; only navigate is blocked.)
Steps to Reproduce
Steps to Reproduce
- Install Claude Desktop 1.6608.0 on Windows 11.
- Install the "Claude in Chrome" extension and sign in with the same account.
- In Claude Desktop, go to Settings → Konnektoren and enable "Claude in Chrome".
- Go to Settings → Claude in Chrome (under the Desktop-App section).
- Set "Standard für alle Websites" to "Erweiterung blockieren" (block by default).
- Click "Websites hinzufügen" and add a domain (e.g.
vespa-suedpfalz.de). Confirm the toast "Erlaubte Websites aktualisiert" appears and the domain shows up in the "Erlaubte Seiten" list. - Open a Claude Desktop chat. The Chrome MCP tools (
tabs_context_mcp,navigate,computer, etc.) load successfully. - Call
tabs_context_mcpwithcreateIfEmpty: true→ succeeds, returns a validtabId. - Call
navigatewith thattabIdandurl: "https://vespa-suedpfalz.de"(a whitelisted domain).
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
latest version
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗