Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Claude Desktop "Claude in Chrome" allowlist not respected — MCP navigate returns permission_required for whitelisted domains

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

=== 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.)

Root Cause

navigate should succeed because the domain is on the allowlist. The browser should load the page and subsequent screenshot calls should work.

Fix Action

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.

Code Example

Get-ChildItem "HKCU:\Software\Google\Chrome\NativeMessagingHosts" |
    Where-Object { $_.PSChildName -like "*anthropic*" }

---

com.anthropic.claude_browser_extension

---

actions[0] (navigate) failed: permission_required: vespa-suedpfalz.de (0 completed, N remaining)

---

Get-ChildItem "HKCU:\Software\Google\Chrome\NativeMessagingHosts" |
    Where-Object { $_.PSChildName -like "*anthropic*" }

---

com.anthropic.claude_browser_extension

---

=== 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.)
RAW_BUFFERClick to expand / collapse

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 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 claude returns 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

  1. Install Claude Desktop 1.6608.0 on Windows 11.
  2. Install the "Claude in Chrome" extension and sign in with the same account.
  3. In Claude Desktop, go to Settings → Konnektoren and enable "Claude in Chrome".
  4. Go to Settings → Claude in Chrome (under the Desktop-App section).
  5. Set "Standard für alle Websites" to "Erweiterung blockieren" (block by default).
  6. 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.
  7. Open a Claude Desktop chat. The Chrome MCP tools (tabs_context_mcp, navigate, computer, etc.) load successfully.
  8. Call tabs_context_mcp with createIfEmpty: true → succeeds, returns a valid tabId.
  9. Call navigate with that tabId and url: "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_browser works (paired with "Arbeits Laptop")
  • ✅ Tab group creation works (tabs_context_mcp with createIfEmpty: true returns 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:

  1. Written to a location the MCP browser tool's permission check does not read from, or
  2. Read at startup but not re-evaluated after edits, or
  3. 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 navigate reads 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 navigate call so users can debug.
  • Surface a permission prompt (in the sidepanel or as a Chrome notification) when navigate hits a domain not in the allowlist, instead of silently returning permission_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 claude returns 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:

  1. Load the URL in the MCP-managed tab
  2. Allow subsequent screenshot, get_page_text, javascript_tool, etc. calls on that tab
  3. 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

  1. Install Claude Desktop 1.6608.0 on Windows 11.
  2. Install the "Claude in Chrome" extension and sign in with the same account.
  3. In Claude Desktop, go to Settings → Konnektoren and enable "Claude in Chrome".
  4. Go to Settings → Claude in Chrome (under the Desktop-App section).
  5. Set "Standard für alle Websites" to "Erweiterung blockieren" (block by default).
  6. 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.
  7. Open a Claude Desktop chat. The Chrome MCP tools (tabs_context_mcp, navigate, computer, etc.) load successfully.
  8. Call tabs_context_mcp with createIfEmpty: true → succeeds, returns a valid tabId.
  9. Call navigate with that tabId and url: "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

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#API routing#API middleware#SSR setup#ISR setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING