[BUG] "Claude in Chrome" website permission ("Allow all websites") not honored — all navigation outside one previously-used domain blocked

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Aug 3, 2026

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?

Browser navigation via the "Claude in Chrome" connector (and the in-app browser in Claude Code Desktop) is blocked for every domain except one that was used earlier in the day (apollo.io) — even though the website-permissions setting is set to "Allow all websites" with an empty blocked-sites list. This worked fine yesterday (2026-08-02); today (2026-08-03) it fails consistently. Already tried: disconnecting/reconnecting the browser, fully restarting the Claude Desktop app, and testing in a brand-new conversation — none of that fixed it.

What Should Happen?

With "Allow all websites" selected and no domains in the block list, Claude should be able to navigate to any website via the connected browser (e.g. avast.com, linkedin.com, google.com, example.com).

Error Messages/Logs

Navigation to this domain is not allowed

Steps to Reproduce

  1. Use the "Claude in Chrome" connector in a Claude Code Desktop (Windows) session.
  1. Successfully navigate to apollo.io (works).
  1. Attempt to navigate to any other domain, e.g. https://example.com/ or https://www.avast.com/.
  1. Observe "Navigation to this domain is not allowed", even though Settings → Claude in Chrome → Website Permissions shows "Allow all websites" and the blocked-sites list is empty.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.220

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

even a completely neutral test domain (example.com, no security/anti-bot measures of its own) is blocked the same way, which rules out the target site blocking the connection — the rejection happens client-side before any request is sent.

View original on GitHub ↗