Claude in Chrome: navigate fails with "Navigation to this domain is not allowed" for every domain, despite all permissions being fully open

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?

Environment:

Claude Desktop (Windows), entrypoint claude-desktop
Claude in Chrome extension, version 1.0.85 (Beta)
Chrome, Windows 11

Summary:
Browser-automation navigate calls from a Claude Code session (via the mcp__claude-in-chrome__navigate tool / "the built-in browser in Claude Code Desktop") fail unconditionally with Navigation to this domain is not allowed — for every domain tested, including trivial ones like example.com and google.com. This happens even though every relevant permission surface is fully open.

Steps to reproduce:

In Claude Code (Claude Desktop), call the Chrome browser-automation tool to navigate to any URL.
Observe the call fails with Navigation to this domain is not allowed.

What I checked/tried, all with no change in behavior:

Claude Code's own settings.local.json permissions already unconditionally allow the navigate tool (mcp__claude-in-chrome__navigate with no domain scoping) — confirmed by reading the file directly.
Chrome extension's own site-access setting: "On all sites" (checked via chrome://extensions).
Claude Desktop → Settings → Claude in Chrome: "Default for all sites" = Allow all sites, "Blocked sites" = none. That page states it also governs "the built-in browser in Claude Code Desktop and Cowork."
Toggled Enable Claude in Chrome off and back on (to force re-pairing) — no change.
Fully removed and reinstalled the Chrome extension — no change.
Fully quit and relaunched Claude Desktop — no change.
Confirmed the extension itself works normally: using its own built-in side-panel chat (a separate feature from Claude Code's browser tool), I was able to ask it to navigate to google.com and it succeeded immediately.
tabs_context_mcp (a read-only call) succeeds every time and returns a fresh tab/tab-group; only the mutating navigate call is refused. Every attempt spins up a new isolated tab group, and each one fails identically.

What Should Happen?

Expected: navigate should succeed given the extension is installed, signed in, connected, and every configurable permission (local settings, extension site access, account-level Claude in Chrome settings) explicitly allows it.

Error Messages/Logs

Actual: Unconditional refusal, identical error, zero variance across ~10+ attempts spanning a computer restart, a Google account password change, extension reinstall, and app relaunch.

Additional context: This surfaced mid-session as an "Authentication failed. The extension may need to be re-authenticated" error before a computer restart; after the restart it changed to the "Navigation to this domain is not allowed" error described above, suggesting some progress was made in re-establishing a connection but something in the domain-check step of that connection is still broken.

Steps to Reproduce

Steps to reproduce:

In Claude Desktop, start a Claude Code session in any project directory.
Ask Claude to open a URL in the browser (this invokes the Chrome browser-automation tool, mcp__claude-in-chrome__navigate).
Claude first calls the tab-context/list call (read-only) — this succeeds and returns a fresh tab group with one blank tab.
Claude then calls navigate with that tab's ID and a target URL (tested with https://example.com, https://google.com, and a specific app URL).
The call returns immediately with the error: Navigation to this domain is not allowed — no browser window changes, no popup or consent dialog appears on screen.
Repeat step 3–5 with a different target URL, or after creating a new tab group — same error every time, for every domain tried (nothing was ever actually allowed, including previously-visited domains).

Things tried in between reproduction attempts, each followed by re-running steps 3–5 with identical results:

Confirmed Claude Desktop → Settings → Claude in Chrome → "Default for all sites" = Allow all sites, Blocked sites = none.
Checked chrome://extensions → Claude → Site access = "On all sites."
Toggled Claude Desktop → Settings → Claude in Chrome → "Enable Claude in Chrome" off, then back on.
Removed the Claude extension from Chrome entirely, reinstalled it from the Chrome Web Store, signed back in.
Fully quit Claude Desktop (via system tray, not just closing the window) and relaunched it.
In between each of the above, confirmed via a read-only tab-list call that the extension connection itself is alive (it always returns a valid tab group) — only the mutating navigate call fails.
As a control, opened the Claude extension's own built-in side-panel chat (separate from Claude Code) and asked it directly to "navigate to google.com" — this succeeded instantly, proving the extension, Chrome, and account auth are all functioning normally outside of the Claude Code Desktop bridge.

None of steps 1–5 changed the outcome in step 4–5 — the error was byte-identical across all ~10+ attempts.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

From the session's environment info: Claude Code (CLI) version: 2.1.246 (from the execpath: ...\claude-code\2.1.246\claude.exe) Claude Desktop app version: 1.40609.0 (from the Sentry release tag in this session's environment) Claude in Chrome extension version: 1.0.85 (already in the draft, from the extension details page) I'll fold those into the Environment section of the report: Environment: Claude Desktop (Windows) version 1.40609.0, entrypoint claude-desktop Claude Code (CLI) version 2.1.246 Claude in Chrome extension version 1.0.85 (Beta) Chrome, Windows 11

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_