Claude in Chrome silently blocks navigation to specific domains despite "Allow all sites" and per-site approval, surviving toggle and reinstall

Environment:

• OS: Windows 11 Pro
• Claude Code CLI, claude-in-chrome MCP tools
• Extension setting: "Default for all sites" = "Allow all sites"; target domains shown under "Your approved sites" in the extension's own settings UI

Summary:
navigate, computer (screenshot), and read_page all fail with domain-specific denial errors on substack.com and www.instagram.com, while medium.com and search.google.com work normally in the same session, same tab group, same extension state. The block persists across an extension off/on toggle and a full uninstall/reinstall, and applies even to a tab the user opened manually (not one the agent navigated to).

Steps to reproduce:

1. With the extension installed, logged in, "Default for all sites" set to "Allow all sites", and the target domain listed under "Your approved sites":
2. Call tabs_context_mcp (fresh), then navigate to https://substack.com or a subdomain.
3. Observe: Navigation to this domain is not allowed.
4. Call navigate to https://medium.com/... in the same tab/session: succeeds normally.
5. As a control, navigate to a never-visited neutral domain (https://example.com): also silently blocked, no grant popup shown, contradicting the "Allow all sites" default.

Additional evidence — manual-tab workaround also blocked:

1. User manually opens substack.com in the browser (agent never calls navigate). The tab appears correctly in tabs_context_mcp's tab list.
2. Agent calls computer with action: screenshot on that tab: Permission denied for this action on this domain.
3. Agent calls read_page on that tab: Permission denied for reading pages on this domain.
4. So the block is not specific to navigate, nor to who/what opened the tab — it's a per-domain gate on every action type, each producing its own distinct error string.

Ruled out (tested directly, not assumed):

• Subdomain-vs-bare-domain scope mismatch — both blocked identically.
• Client-side domain allowlist in Claude Code's own config (~/.claude.json, ~/.claude/settings.json) — grepped, no such allowlist exists there; the gate is inside the extension.
• Call-order sensitivity (fresh tabs_context_mcp immediately before the action) — retested multiple times, no effect.
• Transient/in-memory extension state — extension toggled fully off (confirmed via "Browser extension is not connected") then back on; block persists, Medium still works immediately after.
• Stale local extension storage — full uninstall + reinstall performed; block persists identically, Medium still works immediately after.

Distinct error strings observed (4 total, across this and an earlier session):

• Navigation to this domain is not allowed
• Permission denied by user (seen in an earlier session, before a since-reverted fix)
• Permission denied for this action on this domain
• Permission denied for reading pages on this domain

Expected: A domain listed under "Your approved sites" with "Default for all sites: Allow all sites" should be navigable/actionable, or at minimum should trigger a visible grant prompt rather than a silent denial.

Question: Is there a hardcoded domain or domain-category restriction (e.g. social media / newsletter publishing platforms) in claude-in-chrome that overrides the user-facing site-approval settings? If so, documenting that behavior (and which categories/domains it covers) would save significant troubleshooting time for anyone hitting this.