[FEATURE] User-controlled allowlist override for server-side domain blocks (Claude in Chrome)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The Claude in Chrome extension blocks navigation and DOM reading on certain domains via a server-side classification, with no user-configurable override on personal accounts. Two specific problems result:
No user agency on blocked domains. Even on personal Max/Pro accounts, with the user actively supervising via "Ask before acting" mode, blocklisted domains are absolutely unreachable. The block bypasses the human-in-the-loop model the extension is built around.

The error message is misleading. When a domain is blocked by Anthropic's classification, the extension displays "This site is blocked by your organization's policy" — even on personal accounts with no organization and no managed Chrome policies. Users reasonably interpret this as their employer surveilling them, their machine being compromised, or the extension being broken. None of those are true. The block originates from Anthropic's own server, and the message should say so.
Concrete example: I tried to use DuckDuckGo as a search engine for supervised research on Claude in Chrome v1.0.69 (Max plan). Navigation was blocked. I then opened DuckDuckGo manually in a separate tab and asked Claude to read the already-loaded results page — that was also blocked. The block is total: no navigation, no reading, no override.

Proposed Solution

Primary: user allowlist with manual-handoff mode

Add a User Allowlist section to Settings → Permissions:

Users can add domains that override the server-side block.
Adding a domain shows a clear warning: "You're overriding Claude's default protections for this site. You accept responsibility for compliance with this site's terms of service. Claude will pause for manual interaction on this domain instead of automating."
When Claude encounters a user-allowlisted domain, it automatically enters the existing manual-handoff mode (the same pattern already used for CAPTCHAs and logins) instead of refusing entirely.
Default behavior for all other users and all other domains is unchanged.

Secondary: accurate error messaging

When a block originates from Anthropic's classification rather than a managed Chrome policy, the error message should attribute it correctly. Suggested wording:

"Claude has been configured not to access this site. If you'd like to proceed manually, you can add this site to your allowlist in Settings → Permissions."

Detection is straightforward: if no managed Chrome policy is present and the block came from the classification API, the message should name Claude/Anthropic as the source — not "your organization."

Alternative Solutions

1. Per-domain confirmation prompt instead of allowlist. When Claude hits a blocked domain, show a one-time confirmation dialog: "Claude doesn't navigate to this site by default. Proceed manually for this session?" Less persistent than an allowlist but lower-friction to implement.
2. Fix only the error message. If the full allowlist feature is out of scope, just changing the misleading wording would be a meaningful improvement on its own. Honest attribution lets users make informed decisions about workarounds and feedback channels.
3. Allow read-only access on blocked domains. Permit read_page on already-loaded tabs even when navigation is blocked. This addresses the "DDG is loaded, just summarize what's there" workflow without enabling automation. Narrower than the full allowlist but covers a common use case.
4. Status quo. Users work around blocks by switching search engines, copy-pasting URLs into chat manually, or stopping use of the extension. This is the current state and the reason I'm filing this issue.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

Scenario: I'm a personal Max-plan user doing supervised research. I prefer DuckDuckGo because of its privacy stance.

Current flow:

1. Ask Claude in Chrome to research a topic via DDG.
2. Claude attempts navigation → blocked.
3. Open DDG manually, run the search, leave the page loaded.
4. Ask Claude to summarize results from the active tab → also blocked.
5. Give up and either switch to Google/Bing or paste URLs by hand into the chat.

Flow with proposed feature:

1. First time I hit the block, see honest message: "Claude doesn't navigate to this site by default. Add to your allowlist?"
2. Add duckduckgo.com to my allowlist with the warning acknowledged.
3. Ask Claude to research a topic via DDG.
4. Claude opens DDG, sees it's user-allowlisted, switches to manual-handoff: "I've opened DuckDuckGo. Run the search you'd like, then click Resume."
5. I run the search myself. Click Resume.
6. Claude reads the result page, navigates to individual non-blocked result domains, summarizes.

This pattern respects DDG's ToS (no automated search submission), respects DDG's bot detection (the search is human-driven), and gives me back the agency I expected when I installed a tool I'm actively supervising.

Additional Context

Priority

Medium. Not a crash or data-loss bug, but a meaningful agency and trust issue:

• The misleading error message portion is closer to a bug and could be addressed quickly.
• The allowlist feature is a larger ask and could ship later.
• Both affect every personal-account user who hits a blocklisted domain, which appears to be a non-trivial population based on existing GitHub issues describing similar blocks (#41034, #43279, #50157).

Feature Category

Configuration and settings
(Reasoning: this is fundamentally about user-configurable permission settings for the Claude in Chrome extension. If a "Browser extension" category becomes available, that would be more precise.)

Environment

Plan: Max
Extension version: 1.0.69
Browser: Chrome (latest stable)
OS: Windows
Managed policies present: Only LocalNetworkAccessAllowedForUrls (Source: Platform), set locally by OneDrive/M365. Unrelated to this issue and confirms no enterprise Chrome policy is in play.