Claude in Chrome: every page call denied, including read_page on a blank tab with no URL

Claude in Chrome: every page-touching call denied, including on a blank tab the integration created itself

Component: Claude in Chrome extension / mcp__claude-in-chrome__* MCP server
Severity: Blocking — connection succeeds, then no page operation of any kind works
Host: Claude Code on Windows 11, extension connected, signed in, enabled
Observed: 2026-08-24, and previously 2026-08-23 with identical symptoms

This report is deliberately limited to observations. I do not know the cause,
and two plausible-sounding explanations have already turned out to be wrong.

Observed behaviour

Connecting works. Everything after it fails.

| Call | Target | Result |
|---|---|---|
| switch_browser | — | ✅ connects |
| tabs_context_mcp | — | ✅ returns full tab list with ids, titles, urls |
| tabs_create_mcp | — | ✅ creates a tab |
| navigate | a normal https site | ❌ Navigation to this domain is not allowed |
| navigate | https://example.com | ❌ Navigation to this domain is not allowed |
| navigate (explicit tabId) | same site | ❌ Navigation to this domain is not allowed |
| find | a user-opened tab | ❌ Permission denied for reading pages on this domain |
| computer (screenshot) | a user-opened tab | ❌ Permission denied for this action on this domain |
| read_page | blank tab, url: "" | ❌ Permission denied for reading pages on this domain |

The part that matters

Every denial message blames a domain. The last row has no domain.
tabs_create_mcp returned that tab with url: "", and reading it was still
refused for "this domain".

Whatever check is running is not evaluating the URL of the target tab, or it is
erroring and being treated as a denial. The message asserts a per-site cause
that cannot apply.

Configuration state, for completeness

Reported here as observations, not as a diagnosis:

• Claude Code Desktop → Claude in Chrome → Site permissions: **"Allow all

sites"**, blocked list empty, captioned *"These permissions apply to Claude
in Chrome and the in-app Browser in Claude Code Desktop" and "Claude works
everywhere except sites you block below"*.

• The extension's own options page → "Your approved sites": **"No sites have

been approved yet"**.

I initially took that empty list to be the cause. The user reports the
extension has worked for them for months with that list empty and that they
have never been prompted to approve a site, so an empty approved-sites list
appears to be the normal state rather than the fault. Noting both readings
because the two screens plainly describe different things and it is not
obvious from the UI which one is authoritative.

Control: the other browser surface works

Same session, same machine, same moment: the in-app Browser pane
(mcp__Claude_Browser__*) navigated to the same site and read it successfully
(navOk: true, page text returned). Network, DNS, proxy and the target site
are not involved. Per the caption above, one setting is supposed to govern both
surfaces, and they behave completely differently.

What would have helped

1. Do not blame "this domain" when the tab has no URL. That message is what

made this take two sessions. State the resolved permission decision and what
it was evaluated against.

1. Fail loudly at connect time. switch_browser and tabs_context_mcp

both report success and then every subsequent call fails. If the extension
is in a state where no page operation can succeed, say so at connect.

1. Expose a permission self-check that reports the resolved state, so this

can be attributed in one call instead of a dozen probes and two wrong
guesses.

Impact

The task was replacing an attached file on ~12 products in a third-party web
dashboard whose public API has no file endpoint. The extension is the only
surface with both the signed-in session and file_upload. With it inoperable,
unattended work becomes manual.