Claude in Chrome: all external (https://) navigation/reading silently blocked mid-session; survives restart, reboot, re-login

Important follow-up: the lockout is session-scoped

The user just confirmed that a different, concurrent Claude Code conversation on the same machine, same account, same Chrome profile, same extension can drive mcp__claude-in-chrome normally — navigating to and reading search.google.com pages without any error — while this session remains fully blocked.

This narrows the diagnosis considerably:

• Not account-scoped
• Not browser/extension-scoped (same extension instance, same deviceId)
• Not OS/profile-scoped
• Not model-scoped (reproduced on two different models in the affected session)
• Is scoped to the individual session/conversation

So once a session enters this state, it appears to be permanently poisoned for browser automation, with no in-session recovery — while sibling sessions are unaffected. The practical workaround for users is to abandon the affected session and start a new conversation, which is worth documenting since it's non-obvious (every local-looking symptom points at browser/extension config, sending users down a long and fruitless troubleshooting path — in our case several hours of checking extension site access, file-URL access, chrome://policy, app restart, app re-login, and a full OS reboot, none of which could possibly have helped).

Suggested improvements, in rough priority order:

1. Make the error message actionable — e.g. Navigation to this domain is not allowed (this session's browser access has been revoked; start a new conversation to restore it) instead of a bare domain-denial string that reads like a config problem.
2. Expose whatever session-level flag causes this, and ideally a way to reset it in-session.
3. Root-cause why a session enters this state at all — there was no visible prompt, denial, or policy event at the moment it flipped.

Correction to my previous comment: it is both model- and session-dependent

My earlier comment claimed this was "not model-scoped." That was wrong — I had incomplete information. Corrected data from the user, now covering all four cells:

| | Sonnet 5 | Opus 5 |
|---|---|---|
| affected session | blocked | blocked |
| sibling session | blocked | works |

So:

• Switching model within the already-affected session does not help (verified directly).
• Starting a fresh session on Sonnet 5 does not help either — it was blocked there too, initially.
• The only combination that works is Opus 5 in a session that has not already been blocked.

Neither variable alone is sufficient; both are necessary. This invalidates the "purely session-scoped" framing in my previous comment.

Possibly a different (or differently-surfaced) failure mode

Worth flagging for triage: in the sibling session the failure surfaced with different wording. That session reported the browser tool as temporarily not responding, attributing it to a "safety classifier error" and separately to a "model availability issue", and suggested retrying later. My session, by contrast, consistently gets hard, immediate, deterministic denials:

• Navigation to this domain is not allowed
• Permission denied for reading page content on this domain

Caveat on provenance: the "safety classifier" / "model availability" phrasing is how the assistant in that session described what it saw, so I can't confirm it as a verbatim tool error string. But if a safety classifier does gate mcp__claude-in-chrome tool calls, and its behavior or availability differs per model, that would explain the whole 2×2 — Sonnet 5 trips it in both sessions, Opus 5 clears it only in a session whose accumulated context (or sticky blocked state) hasn't already poisoned it.

Revised suggestions

1. If a classifier is gating browser tool calls, the denial message should say so. Navigation to this domain is not allowed reads unambiguously like a URL-allowlist/config problem, which is what sent us through hours of checking extension site access, file-URL access, chrome://policy, app restart, app re-login, and a full OS reboot — none of which were relevant.
2. Clarify whether a session can become permanently poisoned. In this session, switching to Opus 5 did not recover it, while a fresh Opus 5 session worked — that asymmetry suggests some sticky per-session state that survives a model change and has no documented reset.
3. If this is model-availability-dependent rather than policy-dependent, the transient framing ("try again later") and the permanent framing ("not allowed") should not be producing the same user-visible outcome.

Much better diagnosis: this is a per-origin allowlist, and it can end up wiped or unfillable

New evidence from the sibling session substantially revises this again. Two distinct behaviors are now visible, which means my earlier "model + session" framing was describing symptoms rather than the mechanism.

The mechanism is per-origin approval

In the sibling session, browser automation is partially working, split by origin:

• search.google.com → allowed, navigates and reads fine
• analytics.google.com → denied

Critically, that session reports that requesting the new origin produces no approval card — it is a hard denial, as if the origin simply is not on an allowlist and there is no way to get it added. Retrying and opening a fresh tab both reproduce it.

In this session, by contrast, every origin is denied, including:

• https://search.google.com (which worked earlier in this same session)
• https://example.com
• chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/options.html — even the extension's own options page

So the two sessions are at different points on the same mechanism: one has a partially-populated allowlist that cannot be extended, the other has an allowlist that appears to have been emptied mid-session.

Suspected trigger in this session: navigate mangles file:// URLs

This session worked normally against search.google.com for many calls, then broke. The last browser action before the break was an attempt to open a local file. navigate prepends https:// to a file:// URL, producing a malformed origin:

navigate(url: "file:///C:/Users/.../report.html")
→ "Navigated to https://file:///C:/Users/.../report.html"

The resulting tab URL is https://file///C:/... and the tab title is literally file. This reproduces reliably — I hit it twice in this session, hours apart. Every https:// origin was denied from that point onward, which is consistent with a bogus file origin being written into per-session permission state and corrupting it.

I want to be careful about how strongly I claim this: the correlation is suggestive, not proven, since a later file:// navigation also produced the same malformed URL without any further observable change (the session was already fully blocked by then). But the URL mangling is a clear bug on its own merits, independent of whether it is the poisoning trigger:

navigate should either handle file:// URLs correctly or reject them explicitly, not silently rewrite them into https://file:///….

Why this matters for the user-facing experience

The denial string Navigation to this domain is not allowed gave no indication that:

1. permissions are tracked per origin,
2. the state is per session,
3. and there is apparently no user-accessible way to inspect or repair the allowlist once it is in a bad state.

Every plausible reading of that message points at browser or extension configuration. In this session that cost several hours of checking extension site access ("On all sites"), file-URL access, chrome://policy, app restart, app logout/login, and a full OS reboot — none of which touch a per-session origin allowlist.

Requests

1. Fix the file:// → https://file:///… rewrite in navigate.
2. Make the denial message name the mechanism — e.g. Origin https://example.com is not in this session's approved origins — so users stop diagnosing it as extension config.
3. Expose the approved-origin list, and a way to add to it or reset it. The sibling session's situation (needs one additional origin, no card offered, no path forward) should not be a dead end.
4. Investigate why the approval card fails to appear for a new origin when the session already has other approved origins.

Resolved question: fresh sessions can acquire new origins; older sessions cannot

Following up on request #4 in my previous comment ("investigate why the approval card fails to appear for a new origin"). We now have the answer, from a three-session comparison on the same machine/account/profile:

| Scenario | Result |
|---|---|
| Recover an already-blocked session | ❌ Impossible — model switch, app restart, re-login, OS reboot all ineffective |
| Previously-working origin in a blocked session | ❌ Also dies (search.google.com had worked for many calls, then was denied) |
| New origin in a fresh Opus 5 session | ✅ Works — analytics.google.com was approved and opened successfully |
| New origin in an older, still-partially-working session | ❌ Denied, and no approval card is offered |

So origin approval is per-origin and per-session, and a session appears to lose the ability to acquire new origins as it ages or after it enters a bad state — while a fresh session grants them normally. Concretely: analytics.google.com was unreachable from the older session but approved without incident in a brand-new one, minutes apart.

This makes the practical workaround "abandon the session and start a new one," which works reliably but is undiscoverable from the error text.

One more note on the user-facing side

There is no user-configurable allowed-domains list for this extension — the only related control is Chrome's own extension "Site access" setting, which was already set to "On all sites" throughout. So when a session reaches this state there is genuinely nothing the user can inspect or change; the earlier suggestion in this thread to check an extension-level domain allowlist was a dead end, because no such UI exists.

Combined with the denial string Navigation to this domain is not allowed, which reads exactly like a configuration problem, this is what drives the multi-hour troubleshooting spiral. Surfacing the real mechanism in the error message — and ideally allowing an in-session origin re-request — would resolve nearly all of the pain here, even if the underlying state bug takes longer to fix.

Additional data point on the trigger

Also worth noting for repro: one transient occurrence produced a different error before settling back into the permanent denial:

The hidden tabs_context_mcp lookup did not respond within 8s.
The Chrome extension may be slow to start or waiting on a permission prompt.

The mention of "waiting on a permission prompt" suggests the approval flow was attempted here but never surfaced a prompt to the user — no card, banner, or dialog appeared in either the app or the browser. Subsequent calls reverted to the hard Navigation to this domain is not allowed.