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 — Claude in Chrome MCP bridge: cannot add new domains to trust list

Versione (Version)

• Claude Code (Desktop): 2.1.142
• Claude in Chrome extension: 1.0.70 Beta
• Chrome: [riempire con chrome://version]
• OS: Windows 11
• Account: [tua email Anthropic, es. [email protected]]
• Data segnalazione: 2026-05-19

Summary (Riassunto)

The MCP bridge between Claude Code (desktop) and the Claude in Chrome extension uses a per-session "approved domains" list (turnApprovedDomains in the extension code) that, in version 2.1.142 + 1.0.70 Beta, appears immutable from the user side: there is no documented or undocumented way to add new domains.

Previously (Claude Code 2.1.128 + earlier extension build) the same flow correctly raised a permission_required event to the user, who could approve a new domain via the in-flight prompt. After updating to 2.1.142 / 1.0.70 Beta, attempts to navigate to any domain not already in the list return a silent deny with Navigation to this domain is not allowed (or Permission denied for JavaScript execution on this domain for javascript_tool). No prompt is shown to the user.

This is a hard regression that blocks any new browser-automation project that requires interacting with a domain not already pre-approved in the user's account.

Steps to reproduce

1. Install Claude Code Desktop 2.1.142 + Claude in Chrome extension 1.0.70 Beta on Windows
2. Open a new Claude Code session in any project directory
3. Create a new MCP tab group (tabs_context_mcp createIfEmpty:true)
4. Try to navigate to any domain that has NOT been pre-approved for the account in the past — e.g. https://wikipedia.org, https://gazzetta.it, https://pub.mandelli.net
5. Expected: the extension should surface a permission_required event so the user can approve the new domain via in-flight prompt (this is the documented behavior in support.claude.com/en/articles/12902446)
6. Actual: the call fails immediately with Navigation to this domain is not allowed. No prompt is shown. No way to approve.

The same account's only operative bridge domain is whatever was previously approved (in our case vendorcentral.amazon.it, approved in a past session months ago). Adding e.g. www.amazon.it (a sibling subdomain of an already-approved domain) is also impossible.

What we have tried (all unsuccessful)

To rule out user error, we tried every documented and undocumented mechanism we could find:

• ✗ Chrome chrome://extensions → Claude → Site access → "On specific sites" → add https://pub.mandelli.net/* (affects Chrome injection only, not bridge)
• ✗ Claude in Chrome extension popup → Settings → Permissions → Approved sites → add domain via UI (the UI lists approved sites but provides no "+Add site" button in 1.0.70; can only revoke)
• ✗ Modify the extension's LevelDB permissionStorage key directly (writes to chrome.storage.local) with a new entry mirroring the format of working entries — confirmed persisted across Chrome restarts, but ignored by the MCP bridge code path
• ✗ Modify Claude Code's .claude/settings.local.json:
  • permissions.allow: ["WebFetch(domain:pub.mandelli.net)"] (only affects WebFetch sandbox, not bridge)
  • sandbox.network.allowedDomains: ["pub.mandelli.net", "*.mandelli.net"] (same)
  • Various defaultMode values: bypassPermissions, default, acceptEdits, plan → no change
• ✗ Kill all Chrome processes (incl. chrome-native-host.exe) + restart Chrome
• ✗ Disable + re-enable extension (forces config reload)
• ✗ Hard reload pages (Ctrl+Shift+R)
• ✗ Full PC restart + Claude Code app update to latest

The sidepanel chat within Claude in Chrome can successfully prompt for and grant the same domain — meaning the sidepanel has its own working permission flow, but the MCP bridge does not.

Technical analysis (from extension source code)

The check in assets/PermissionManager-BqJmxUlR.js (class Fy, method checkPermission) is:

async checkPermission(t, e, n) {
  const r = new URL(t).hostname;
  if (r && this.turnApprovedDomains.size > 0 && !this.isTurnApprovedDomain(r))
    return { allowed: false, needsPrompt: false };   // ← silent deny here
  ...
}

The turnApprovedDomains Set is populated in assets/mcpPermissions-X6RKG-4F.js:

if (e.source === "bridge") {
  const t = function(e, t) {
    if (!e || "ask" === e) return;
    const r = "skip_all_permission_checks" === e;
    const o = new _(() => r, {});
    return "follow_a_plan" === e && t?.length && o.setTurnApprovedDomains(t), o
  }(e.permissionMode, e.allowedDomains);
}

So turnApprovedDomains is populated only when Claude Code sends permissionMode: "follow_a_plan" + a non-empty allowed_domains array.

In claude.exe 2.1.142 the code path that builds the message to the bridge is:

let j = $?.permissionMode ?? this.permissionMode;
let w = $?.allowedDomains ?? this.allowedDomains;
let D = { type: "tool_call", ..., args: q };
if (j) D.permission_mode = j;
if (w?.length) D.allowed_domains = w;

this.allowedDomains is set somewhere we could not locate in the obfuscated binary, but empirically the list contains exactly one domain (the one previously approved months ago) and no setting from .claude/settings.local.json changes it.

Comparison with working session (regression evidence)

In a session from 2026-05-10 in a different project directory, Claude Code 2.1.128:

• permissionMode: "acceptEdits"
• Successfully navigated to https://www.amazon.it, https://members.helium10.com
• For a fresh domain (http://127.0.0.1:8000), tool result was:

  actions[0] (navigate) failed: permission_required: 127.0.0.1

  which is the documented needsPrompt: true flow that surfaces a prompt to the user.

In current Claude Code 2.1.142 same permissionMode, fresh domain pub.mandelli.net:

• Tool result is: Navigation to this domain is not allowed
• No prompt is surfaced. The user has no way to approve.

Impact

For us: this completely blocks a customer automation project (Mandelli Vendor Central integration). The only workaround is manual file export, defeating the purpose of using Claude in Chrome.

More broadly: any new project requiring interaction with a non-pre-approved domain via the MCP bridge is non-functional.

Request

1. Confirm whether the in-flight prompt regression is a known issue (potentially related to issue #58464 on GitHub) and an ETA for fix
2. If the trust list is indeed account-bound server-side, provide a documented mechanism (CLI, settings, UI) to add a domain
3. If there is a temporary workaround (env var, debug flag, beta channel) please share

Thank you.

What Should Happen?

When the navigate tool is called with a URL whose hostname is not in the bridge's turnApprovedDomains list, the extension should return a permission_required event, surfacing an in-flight prompt to the user. The user should be able to click "Always allow" to add the domain to the trust list. This is the documented behavior in https://support.claude.com/en/articles/12902446 and the actual behavior in Claude Code 2.1.128 (verified empirically against an older session).

Instead, the call fails immediately with Navigation to this domain is not allowed, no prompt is surfaced, and there is no documented way for the user to add the domain.

Error Messages/Logs

// navigate to pub.mandelli.net (a new domain)
> mcp__Claude_in_Chrome__navigate({ tabId: 1313589639, url: "https://pub.mandelli.net" })
Error: Navigation to this domain is not allowed

// javascript_tool on same domain
> mcp__Claude_in_Chrome__javascript_tool({ tabId: 1313589639, action: "javascript_exec", text: "1" })
Error: Permission denied for JavaScript execution on this domain

// Same call on previously-approved domain works fine:
> mcp__Claude_in_Chrome__navigate({ tabId: 1313589639, url: "https://vendorcentral.amazon.it/home/vc" })
Navigated to https://vendorcentral.amazon.it/home/vc

Steps to Reproduce

1. Install Claude Code Desktop 2.1.142 + Claude in Chrome extension 1.0.70 Beta on Windows
2. Start a new Claude Code session in any project directory
3. Open Chrome, sign in to your Claude in Chrome extension
4. From Claude Code, create an MCP tab group: tabs_context_mcp({ createIfEmpty: true })
5. Have the user manually navigate that tab to any domain NOT previously approved for the account, e.g. https://wikipedia.org or https://pub.mandelli.net
6. From Claude Code, call: mcp__Claude_in_Chrome__javascript_tool({ tabId: <id>, action: "javascript_exec", text: "1" })
7. Observe: returns "Permission denied for JavaScript execution on this domain" silently. No prompt shown to user.
8. Expected: extension surfaces a permission_required event → user sees Always allow / Allow once / Deny prompt.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.128

Claude Code Version

2.1.142

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

• Extension trust list inspected via direct LevelDB read at: %LOCALAPPDATA%\Google\Chrome\User Data\Default\Local Extension Settings\fcoeoabgfenejglbffodgkkbkcdhcgfn
  key permissionStorage shows our manually-added entries but the bridge ignores them.

• Static analysis of extension source (mcpPermissions-X6RKG-4F.js, PermissionManager-BqJmxUlR.js) shows the check fails at: if (turnApprovedDomains.size > 0 && !isTurnApprovedDomain(hostname)) return { allowed: false, needsPrompt: false };

• Static analysis of claude.exe 2.1.142 shows allowed_domains is sent per tool_call from a this.allowedDomains field we could not trace to a user-configurable source.

• Related issue: #58464 (approved sites still blocked by MCP navigate).

• Working comparison: session 3055c15b-... in C:\Users...\Flocky\Monitoraggio (Claude Code 2.1.128, extension prior version) successfully prompted for and approved new domains during MCP navigate. Same code paths now silently deny.