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

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] 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.)

1. Attempt navigation to ANY site:

mcp__Claude_in_Chrome__navigate { url: "https://example.com/" }
-> FAILS: "Navigation to this domain is not allowed"

1. Repeat with a different domain to show it is not site-specific:

mcp__Claude_in_Chrome__navigate { url: "https://www.lasection8.com/" }
-> FAILS identically.

1. Attempt a screenshot of the current tab:

mcp__Claude_in_Chrome__computer { action: "screenshot", tabId: <current tab> }
-> FAILS: "Permission denied for this action on this domain" (fails even on chrome://newtab/).

1. 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 #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).