[BUG] Claude in Chrome MCP: navigate and read_page denied on ALL domains from Claude Desktop (Windows 11) — no approval popup renders

Same issue, macOS, Chrome (latest, auto-updated this session). Extension v1.0.69 (clean install on fresh Chrome profile).
Service worker console errors (in order):
mcpPermissions-BSnCI2j1.js:1 Uncaught (in promise) Error: Could not establish connection. Receiving end does not exist.
Unchecked runtime.lastError: Cannot access a chrome:// URL
Unchecked runtime.lastError: Debugger is not attached to the tab with id:
After full extension reinstall + Chrome force-quit, only Debugger is not attached remains. After full Chrome uninstall + profile reset (mv ~/Library/Application\ Support/Google/Chrome ...backup) + fresh Chrome install + fresh extension install + Claude account sign-in, same Debugger is not attached error persists.
Reproduces on every domain tested: example.com, bst.cisco.com, google.com. Not site-specific. Worked normally 2 days ago — no user-initiated changes since.
Permission state: "On all sites" granted at install time. Approved Sites list at chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/options.html does not persist additions via Manage Extension, Options page, or click-to-grant. No runtime permission prompt appears anywhere in any window.
Symptom from MCP layer: every browser action (screenshot, get_page_text, navigate) returns permission_required: regardless of site or permission state.
Filing because this is the third confirmed case of this defect chain and I've fully eliminated every user-side variable.

This is approval-surface failure at the browser-control boundary.

If Claude in Chrome MCP denies navigate and read_page on all domains from Claude Desktop on Windows 11 because no approval popup renders, then the system is not just blocking actions — it is failing to present the very consent mechanism that should let the operator decide.

Why it matters:

• browser-control tools often sit behind explicit approval by design
• if the approval surface never appears, users see only denial without any path to authorize legitimate work
• the result is a dead control path that looks like policy, but is really UI/consent delivery failure

I would want clarity on:

1. whether the denial is happening because the approval request is never emitted, emitted but not rendered, or rendered outside the visible surface
2. whether all domains fail because the approval system itself is broken, rather than any domain-specific rule
3. whether the runtime can distinguish denied by policy from approval UI failed to render so users can troubleshoot the right layer

Consent gates only work if the gate is visible. If approval UI failure is translated into blanket denial, the operator loses both control and debuggability.

1. Testing was done with "On all sites" approved, "On-click", and via "Specific site list" and none worked.
2. With On-Click, no pop-up was seen even though pop-ups were enabled for all sites. I needed to manually click on Extensions icon in the browser to show that message requiring a click to allow. Even doing that and reloading, Claude Desktop was still not able to access the site and the site would not show on the "Specific Site List" afterwards or the "Approved sites" list on the options page for the extension
3. When manually adding the site to the "Specific site list", it never shows up in the "Approved sites" on the options page for the extension.

hope that helps with your research

Same issue on Claude for Chrome extension v1.0.70 (Chrome Web Store build).

Setup: Windows, Google Chrome, Team plan, no org allowlist/blocklist, permission mode "Ask before acting".

Repro: Try any action on a previously unapproved domain. Every action returns permission_required: <domain>. No approval popup, no toolbar badge, no notification. "Your approved sites" stays empty and there's no UI to add a site manually.

Workaround unavailable: The "Ask before acting" dropdown in the side panel input is unresponsive — clicking it does nothing, so I can't switch to "Act without asking" either.

End-state matches the original report: extension fully blocked for new domains with no way forward through the UI.

A fix or a documented manual workaround (e.g., seeding an approved site via extension storage) would be appreciated. Happy to provide logs if useful.

Same issue on Claude for Chrome 1.0.70 (Chrome Web Store build) on Windows.

Permission mode has no bearing on the outcome. Claude for Chrome works as expected, but the connection between Claude Code in VS Code and the Chrome extension doesn't trigger any permission request, and since the permission list in the Chrome extension can only be auto-populated, it's not possible for me to use this connection. Completely blocked.

Same on Claude for Chrome 1.0.70 Version 148.0.7778.168 (Official Build) (arm64) for macOS Tahoe 26.4.1.

Claude Code analysis:
Same OS (macOS, latest Chrome)
Same MCP error string: every browser action returns permission_required: — that's exactly what I saw in our session (permission_required: mega.io)
No popup appears anywhere — matches "I see no popup at all"
Not site-specific (also fails on example.com, google.com) — matches my example.com test
"On all sites" permission granted but doesn't propagate to the extension's Approved Sites list — matches the fact that you said you'd granted permission yet it kept denying

Underlying mechanism (from the console errors in the comment):
The service worker is throwing Could not establish connection. Receiving end does not exist. from mcpPermissions-*.js and Debugger is not attached to the tab with id:. That tells me the permission/approval bridge between the extension's service worker and the Cowork-side MCP layer is broken — so the MCP layer auto-fails with permission_required: because it can't even reach the approval flow. That's why no popup ever renders: the popup-triggering pathway is dead.

Has it been picked up?
Still no. The page metadata I can read shows no assignee, no PR, no milestone, no project — only triage labels. Your case would be the fourth confirmed report. Worth commenting on the issue with your macOS repro and the permission_required: error string to push for attention and to get the platform:windows label corrected.

Until Anthropic ships a fix, your realistic options for the baseline are: (a) you paste page content/screenshots into chat and I structure them into the PDF, or (b) wait for a fix.

This also blocked all access to Chrome Connector from "Code" tab in the Dektop app on Mac, not just chat. I was trying to transfer some co-work tasks into Claude Skills and it turned out to be impossible.

Still reproduces on the latest builds (Claude Code 2.1.142, Claude-in-Chrome v1.0.77, Brave 1.91.175 / Chromium 149, Windows 11). Adding forensic data that localizes the failure below the extension host-permission layer.

Confirmed NOT the cause (with evidence):

• Brave host permissions are fully granted. Secure Preferences -> extensions.settings.<id> shows granted_permissions.explicit_host = <all_urls>, active_permissions.explicit_host = <all_urls>, withholding_permissions = false. "On all sites" is genuinely active, so the deny is not a withheld-host issue.
• No local allowlist exists to clear. The extension Local Extension Settings\<id> LevelDB is essentially empty (~19 B, re-created on reinstall). "Your approved sites" can only be auto-populated, and the popup that would populate it never renders, so it stays empty permanently.
• No native-messaging host is registered for the extension (checked HKCU/HKLM NativeMessagingHosts). The bridge is a WebSocket/cloud relay (consistent with list_connected_browsers returning a cloud deviceId), so the navigate/read allow-decision is made relay/server-side, not locally. That explains why it survives browser restart, extension reinstall, and fresh device pairing -- there is nothing client-side to reset.
• tabs_context_mcp works (returns tab IDs) while navigate/read_page are denied: the bridge connects but the per-domain gate denies everything.

Regression window: matches reports that this broke ~v2.1.111 (worked in v2.1.92); still present in 2.1.142.

Working workaround (bypasses the broken MCP entirely via Playwright over CDP):

1. npm i playwright-core
2. Launch a separate instance with a custom profile dir + debug port: brave.exe --user-data-dir="<custom dir>" --remote-debugging-port=9222 (the default user-data-dir is blocked by Chromium remote-debugging mitigation, so a custom dir is required; it runs alongside the main browser).
3. chromium.connectOverCDP('http://127.0.0.1:9222') -> navigate/read/fill work on all domains. (Logged-in tasks need the real profile cookies -- copy the profile or sign in inside the CDP instance.)

Possible gating flag for maintainers: ~/.claude.json contains GrowthBook flag tengu_chrome_auto_enable = false.

3 weeks since the last comment, still failing with the latest versions of Claude in Chrome and Claude Desktop on MacOS. Am I paying for this product or what? C'mon guys, this is a really bad look for Claude.

Anthropic isn’t interested in fixing critical issues. The first reports of this problem surfaced back in April. It’s already mid-July. Imagine how long some users have been unable to work. Were they really supposed to pay for a product that doesn’t work?

By the end of this month, I’ll completely stop using Claude on both my personal and work computers until Anthropic fixes this critical bug, which it hasn’t been able to resolve for 4.5 months now.

You don’t care about your users. But you’re telling everyone about the launch of Fable. Ha ha. Fable? Your models aren’t working the way they should, and you’re launching Fable? Stop paying this company for its disregard for its users.