[BUG] Claude in Chrome extension blocks navigation to all domains except one specific site (behaves like an allowlist)

Same symptom here, plus a new data point: the "Allowed sites" UI that is supposed to fix this is itself broken, so there is no recovery path.

Environment

• Extension fcoeoabgfenejglbffodgkkbkcdhcgfn v1.0.81 (this issue reports v1.0.79)
• Reproduced on both macOS and Windows — two machines, same account, both connected to Claude Code
• Chrome site access set to On all sites
• Target origin: http://60.205.188.223:8054 (internal system: plain HTTP, IP address, non-standard port)

The allowlist cannot be populated

Settings → Claude in Chrome → Allowed sites shows "No sites have been approved yet". Every URL entered into "Add URL" is rejected with:

Couldn't verify this site. Please try again. (JA: このサイトを確認できませんでした。もう一度お試しください。)

Tried all of these, all rejected:

https://www.google.com/
https://www.google.com
http://60.205.188.223:8054
60.205.188.223:8054
http://60.205.188.223:8054/iws

https://www.google.com failing too suggests the verification call itself is failing, rather than the URL being rejected on content grounds.

Evidence from extension storage

Chrome host permissions are fully granted — this layer is not the blocker.
~/Library/Application Support/Google/Chrome/Default/Secure Preferences, extension fcoeoabgfenejglbffodgkkbkcdhcgfn:

active_permissions.explicit_host  = ["<all_urls>"]
granted_permissions.explicit_host = ["<all_urls>"]
runtime_granted_permissions       = ["<all_urls>"]
withheld_permissions              = (absent)
disable_reasons                   = []

Managed Extension Settings/<ext id>/ is empty — no enterprise policy involved.

The extension's own per-origin table (Local Extension Settings/fcoeoabgfenejglbffodgkkbkcdhcgfn) explains the "only one domain works" behaviour reported in this issue:

{"permissions":[{"action":"allow","createdAt":1784852308073,"duration":"once",
  "id":"c8a7ff84-5031-4ede-85f5-624772ed29c1",
  "origin":"http://123.56.103.16:8054",
  "scope":{"netloc":"123.56.103.16:8054","type":"netloc"},
  "toolUseId":"75ce7f09-3053-4beb-97a2-474c4ee44b1f"}]}
{"permissions":[]}

• Exactly one grant was ever created, automatically, during the first navigate call of the session.
• It carries duration: "once" — consumed immediately.
• Matching is by netloc (host:port), so it did not cover a different host on the same port.
• After consumption the table went to [] and never received another entry.

That matches this issue's "one specific site works, everything else is blocked": the one working domain is whatever happened to consume that single automatic once grant.

The two permission layers do not communicate

1. Claude Code tool permission — approving mcp__claude-in-chrome__navigate / computer / get_page_text (including "always allow") does not write an entry into the extension's origin table.
2. Extension origin allowlist — the layer that actually gates the action. Its approval UI never appears for MCP-driven calls, and the manual add path fails verification.

Verified directly: removed the "always allow" rules from .claude/settings.local.json, which restored the Claude Code permission prompt; the user approved it; the extension table still stayed [].

Error progression

| Condition | Error |
|---|---|
| Tool auto-approved by a Claude Code allow-rule | Navigation to this domain is not allowed (extension) |
| Allow-rule removed, permission mode = auto | Permission denied by the Claude Code auto mode classifier |
| Permission mode = ask, user approves the prompt | Navigation to this domain is not allowed (extension, again) |
| Page manually dragged into the MCP tab group, then computer / get_page_text | Permission denied for this action on this domain |

The last row matters: with the target page already inside the MCP tab group (the group's stored domain field is 60.205.188.223), non-navigation actions are still refused. So the gate is per-origin, not per-navigation — navigate, computer and get_page_text are all blocked identically.

Impact

Claude Code cannot drive Chrome at all for this account on either machine, and the documented workaround (add the site to the allowlist) is unavailable because the add step is broken.

Related: #58464, #57219, #38378, #36767, #47388.

Same symptom on Windows, plus a root cause trace and a working no-restart workaround.

Environment

• Windows 11 Pro 10.0.26200
• Claude desktop app 1.24012.9.0 (Store install), bundled claude-code CLI 2.1.219
• Extension fcoeoabgfenejglbffodgkkbkcdhcgfn v1.0.84, Chrome site access "On all sites" (Secure Preferences shows <all_urls> granted, no enterprise policy)

Repro

Fresh desktop session, default permission mode: the first domain navigated works (gets an automatic duration: "once" grant), every subsequent domain returns Navigation to this domain is not allowed with no prompt ever shown. Matches this issue and #74366.

Root cause (from the session state + app bundle)

• The desktop app stores a per-session chromePermissionMode and chromeAllowedDomains (visible in %APPDATA%\Claude\claude-code-sessions\<account>\<env>\local_<sessionId>.json). Sessions created in default/acceptEdits permission mode get chromePermissionMode: "follow_a_plan" with the domain list frozen at session start.
• On every CIC tool call the client passes that list as permissionOverrides.allowedDomains. In the extension's checkPermission, a non-empty turnApprovedDomains set causes any other hostname to return {allowed: false, needsPrompt: false} BEFORE the stored-permission lookup and before any prompt path. So the extension's own "Allowed sites" storage is unreachable, and no approval UI can ever fire mid-session, which is the catch-22 several people here hit.
• In unattended turns, the auto-mode classifier answers instead of the user, so the deny is silent there too.

Workaround that does NOT work (any more)

Editing chromeAllowedDomains in the session JSON while the app is quit (suggested upthread): on this app version the session files are deleted on quit and re-materialized from an internal store on launch, so on-disk edits never survive. The files are mirrors, not the source of truth.

Workaround that DOES work, live, no restart

Flip the affected session's permission mode to Auto (or Bypass permissions) in the session's permission-mode picker. computeChromeStateOnPermissionModeChange then clears the lockdown (session becomes skip_all_permission_checks, prior state saved to chromePermsBeforeUnsupervised), and all domains navigate immediately. Verified across framer.com, google.com, example.com, wikipedia.org and others right after the flip. Switching the mode back restores the previous lockdown state.

Suggested fix

Same as proposed above: in checkPermission, a hostname missing from turnApprovedDomains should fall through to needsPrompt: true so newly approved domains can be appended to the session grant list, instead of hard-denying with no recovery path.

Same symptom on v1.0.84, with additional evidence from the extension's local storage that may help narrow this down: the "Always allow actions on this site" button writes a duration: "once" record instead of a permanent one.

Environment

• Claude in Chrome extension: v1.0.84 (auto-updated from v1.0.81 on 2026-07-28)
• Chrome: 150.0.7871.187
• OS: Windows 11 Home 10.0.26200
• Client: Claude Code desktop app (MCP tools mcp__claude-in-chrome__*)
• Site access in chrome://extensions: "On all sites"

Symptom (matches OP)

Within one session, the first domain navigated to works (approval card appears, then full access to that host for the rest of the session). Every subsequent domain fails with Navigation to this domain is not allowed — no approval card is shown, so approval can never be granted. Reproduced across multiple sessions on multiple days.

New evidence: "Always allow" writes once to permissionStorage

I inspected the extension's LevelDB at
%LOCALAPPDATA%\Google\Chrome\User Data\Default\Local Extension Settings\fcoeoabgfenejglbffodgkkbkcdhcgfn\.

Every approval — including one where I explicitly clicked "Always allow actions on this site" (verified at 2026-07-30 00:34 JST) — is stored as:

{"permissions":[{"action":"allow","createdAt":1785339254180,"duration":"once","id":"eef4c39f-...","origin":"https://www.amazon.co.jp","scope":{"netloc":"www.amazon.co.jp","type":"netloc"},"toolUseId":"41b3c7b6-..."}]}

Observations:

1. duration is always "once" — across 4 approvals on 3 different hosts over 2 days, regardless of which button was clicked. No record with duration: "always" (or any other value) was ever written.
2. After the record is consumed, permissionStorage returns to {"permissions":[]}.
3. The extension options page (options.html#permissions → "Your approved sites") remains empty immediately after clicking "Always allow".
4. Grepping the entire LevelDB for plausible permanent-list keys (approvedSites, alwaysAllow, "duration":"always", etc.) returns zero hits, and no Sync Extension Settings directory exists for this extension ID.
5. Curiously, within the same session the first-approved host keeps working even after its once record is consumed and permissionStorage is empty — suggesting a session-scoped in-memory allow that is never persisted.

Why the "only the first site works" behavior follows

Since only one approval card is ever shown per session (for the first navigation), and its stored effect is once/session-scoped, users can never accumulate approved sites — which produces exactly the "behaves like an allowlist of one" behavior in the OP.

Root cause found in the minified source (v1.0.84)

In assets/mcpPermissions-*.js, the MCP retry path grants the permission with a hardcoded ONCE after the prompt is approved, regardless of which button the user clicked:

if (h.url) try {
  const e = new URL(h.url);
  await (t?.permissionManager ?? this.context.permissionManager).grantPermission(
    { type: "netloc", netloc: e.host },
    lA.ONCE,                 // ← hardcoded; the user's ONCE/ALWAYS choice is not propagated
    h.toolUseId,
    e.origin
  )
} catch {}

(lA is the duration enum {ONCE:"once", ALWAYS:"always"}.) grantPermission itself supports always correctly, and the read side honors it — findApplicablePermission matches persistent records with duration !== ONCE, and the navigate tool's checkPermission gate returns allowed for them. I verified this end-to-end by injecting a duration:"always" allow record via chrome.storage.local from the extension's service worker console: navigation to a second and third domain then works across sessions with no prompt.

So the fix appears to be: propagate the user's selected duration through the MCP approval path instead of hardcoding ONCE (and/or surface the extension's own always/once prompt for MCP-originated requests).

Happy to provide the full (redacted) LevelDB excerpts if useful.