[BUG] Claude in Chrome: navigate + screenshot denied on ALL domains; persists through reinstall, Claude Code restart, and claude.ai allowlist

[hotweazel]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Reproducing the same regression others have reported (#65803, #50606, #58464). Driving the Claude for Chrome extension from Claude Code via its MCP tools, every page action is refused on every domain. The connection itself is alive — only page actions fail.

Environment

• OS: Windows 11
• Claude for Chrome extension version: <FILL IN — chrome://extensions, Developer mode on>
• Claude Code version: <FILL IN — app About/Settings, or "unknown">
• Browser: Google Chrome (current stable)

What works vs fails

WORKS (connection/metadata only):

• list_connected_browsers ✅
• select_browser ✅
• tabs_context_mcp ✅

FAILS on every domain:

• navigate -> "Navigation to this domain is not allowed"
• computer/screenshot -> "Permission denied for this action on this domain" (failed even on chrome://newtab)

Blanket, not site-specific

Identical "Navigation to this domain is not allowed" on both a real site (www.lasection8.com) and example.com.

Regression

Same machine + same site navigated fine and took screenshots in earlier sessions, with no config change on my end.

Ruled out (none fixed it)

• chrome://extensions -> Site access = "On all sites"
• Full Chrome restart
• Extension Permissions / approved-sites + permission mode toggles
• Reconnecting the extension to Claude Code
• Full uninstall + reinstall of the extension (confirmed a NEW device ID afterward)
• Restarting Claude Code itself
• claude.ai/settings/browser-extension -> "Default for all sites" = "Allow extension"

Reproduction

1. Connect the extension to Claude Code (list_connected_browsers succeeds, so it's connected).
2. Call navigate to any URL -> "Navigation to this domain is not allowed".
3. Call a screenshot via the computer tool on any tab -> "Permission denied for this action on this domain".
4. tabs_context_mcp / list_connected_browsers still succeed -> connection is alive; only page actions are denied.
5. No site-approval prompt ever appears, so there is no way to grant permission from the UI.

Expected

Agent-initiated navigation and screenshots should work on approved sites (as they did before), or the site-approval prompt should appear so the site can be allowed.

What Should Happen?

Agent-initiated browser actions (navigate, screenshot, read_page, find) should succeed on permitted sites, the way they did in earlier sessions before this regression.

Specifically:

• Calling navigate to a normal site (e.g. https://www.lasection8.com/ or https://example.com/) should load the page, not return "Navigation to this domain is not allowed."
• screenshot / computer actions should capture the page, not return "Permission denied for this action on this domain."
• If a site hasn't been approved yet, the extension should surface a site-approval prompt ("Allow actions on this site") so I can grant access — instead of silently denying every domain with no way to approve.

In short: connection tools already work (the extension is clearly connected), so page actions on approved/allowed domains should work too.

Error Messages/Logs

Navigation to this domain is not allowed
Permission denied for this action on this domain

Steps to Reproduce

1. Install the "Claude for Chrome" extension in Google Chrome (Windows 11) and sign in.
2. Connect the extension to Claude Code (CLI) so its MCP tools are available (tools named mcp__Claude_in_Chrome__*).
3. Confirm the connection is live — call:
   mcp__Claude_in_Chrome__list_connected_browsers -> returns the browser
   mcp__Claude_in_Chrome__select_browser -> "Connected to browser"
   mcp__Claude_in_Chrome__tabs_context_mcp -> returns the tab list
   (All three succeed, proving the extension is connected.)
4. Attempt navigation to ANY site:
   mcp__Claude_in_Chrome__navigate { url: "https://example.com/" }
   -> FAILS: "Navigation to this domain is not allowed"
5. Repeat with a different domain to show it is not site-specific:
   mcp__Claude_in_Chrome__navigate { url: "https://www.lasection8.com/" }
   -> FAILS identically.
6. Attempt a screenshot of the current tab:
   mcp__Claude_in_Chrome__computer { action: "screenshot", tabId: }
   -> FAILS: "Permission denied for this action on this domain" (fails even on chrome://newtab/).
7. Observe that NO site-approval prompt appears in the extension at any point, so there is no UI path to allow the domain.

Result: every page action (navigate/screenshot/read) is denied on every domain, while connection/metadata tools keep working.

Already tried (none fixed it), in case it helps reproduction/triage:

• chrome://extensions -> Claude -> Site access = "On all sites"
• Full Chrome restart
• Extension Permissions / approved-sites + permission-mode toggles
• Reconnect extension to Claude Code
• Full uninstall + reinstall of the extension (new device ID confirmed afterward)
• Restart Claude Code
• claude.ai/settings/browser-extension -> "Default for all sites" = "Allow extension"

No special code or files are needed — this reproduces on any URL with a default setup.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

Version 1.15962.1 (1e236d)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Triage notes:

• The connection is healthy; this is purely a permission/allowlist gate. list_connected_browsers, select_browser, and tabs_context_mcp all succeed, so the native-messaging bridge and the extension are connected and talking. Only the actual page-action calls are gated and denied.

• The denial happens with NO approval prompt. The expected flow ("Permission required" -> "Always allow actions on this site" -> domain joins approved sites) never fires, so there is no user-facing path to grant access. This matches mcp__Claude_in_Chrome__navigate silently denies non-pre-approved domains — no user-facing approval path exists anywhere #50842 ("no user-facing approval path exists anywhere").

• It denies by default even on internal pages. A screenshot of chrome://newtab/ returns "Permission denied for this action on this domain", which suggests the gate is blanket-denying anything not explicitly allowed, rather than checking a real per-domain rule.

• Reproduces on a completely default setup. No special config, MCP server settings, repo, or code is involved — it happens on any URL.

• Everything user-side has been ruled out: chrome://extensions site access = "On all sites"; Chrome restart; extension permission/approved-sites + mode toggles; reconnect; full uninstall + reinstall (new device ID confirmed); Claude Code restart; and claude.ai/settings/browser-extension "Default for all sites" = "Allow extension". None changed the behavior.

• No config files or repository are needed to demonstrate this — it is not project-specific.

Likely duplicates / related (suggest consolidating): #65803 (v1.0.75, all domains), #50606 (v1.0.66+ regression), #58464 (blocks domains even when in "approved sites"), #50842 (no approval path), #49979 (Windows 11, navigate/read_page denied, no popup).

[hotweazel]

Update — behavior shifted as of 2026-06-28 (same machine, no config change):

The blanket block has partially lifted on its own. Current observed state:

• navigate → https://example.com/ ✅ now succeeds
• computer screenshot ✅ now succeeds (works on example.com)
• navigate → https://en.wikipedia.org/ ❌ "Navigation to this domain is not allowed"

So page actions themselves are no longer dead — only the special no-permission
documentation domain (example.com) is reachable. Every real domain is still
refused at the domain level with no approval prompt ever rendering, so
"Your approved sites" stays permanently empty and there is no UI path to grant
access. This now matches the #51273 "all non-claude.ai domains" variant more
than the original full blanket-block.

Claude Code: 1.15962.1 (1e236d). Extension version: <fill from chrome://extensions>.

[bayorgs]

Platform: macOS, Claude desktop app driving the Claude in Chrome extension via MCP.
Summary: All MCP browser actions are denied on every non-approved domain. navigate returns "Navigation to this domain is not allowed"; screenshot/click return "Permission denied for this action on this domain." Confirmed on dashboard.bookfunnel.com and even code.claude.com/docs.
Connection is fine: Chrome shows the transient "'Claude' started debugging this browser" notification (debugger attaches), but the action is then denied — so it's the permission layer, not the connection.
Can't grant permission: The extension's automation "approved sites" list (side panel → Settings → Permissions) is empty and has no add button/field, and the "Always allow actions on this site" approval popup never renders when navigation is attempted. The built-in sidebar's Chrome "site access" shows "has access" everywhere, but that's separate and doesn't help MCP.
Persists through: reinstalling the extension (latest, from the official docs), restarting Chrome, and restarting Claude Code. Reinstall produced a new device ID; allowlist still empty/unfillable.
Impact: Browser automation is completely unusable — there is no user-accessible way to approve a domain.

[localden]

Thank you for taking the time to report this.

We're currently triaging open MCP issues, and this one is being closed in favor of tracking it in #65803, which covers the same "Navigation to this domain is not allowed" failure on all domains via the Chrome integration. Please follow that issue for updates and feel free to add any additional context there.