Claude-in-Chrome: Server-side domain blocking breaks legitimate business automation

Status Closed — not planned
Reported on v2.1.86
Maintainer reply None cached
Activity 12 comments · opened Mar 28, 2026 · closed Aug 12, 2026

Problem

The Claude-in-Chrome extension blocks browser automation on financial sites (Wells Fargo, Charles Schwab, and likely all banking/brokerage domains). The block message is "This site is blocked."

How it works

The extension calls api.anthropic.com/api/web/domain_info/browser_extension?domain=... which returns a category. Categories 1 and 2 trigger blocking. This is a server-side decision with no local override or configuration option.

Why this matters

I'm a small business owner on Maui who has spent hundreds of hours using Claude Code + Claude-in-Chrome for bookkeeping automation: downloading bank statements, reconciling transactions, navigating banking portals. This is core business infrastructure, not casual use.

The blocking appears to be new (or newly enforced). These workflows were working before and are now broken with no workaround.

Request

Please provide one of:

  1. A way for account holders to allowlist domains for their own accounts (opt-in, acknowledging the risk)
  2. An enterprise/business tier setting that permits financial site automation
  3. At minimum, documentation of which domains are blocked and why, so users can plan around it

Environment

  • Claude Code: 2.1.86
  • Claude-in-Chrome extension: 1.0.64
  • macOS Darwin 25.3.0
  • Max plan subscriber

Context

The safety concern (preventing credential theft from untrusted content) makes sense for general use. But a business owner automating their own banking with their own credentials on their own machine is a legitimate use case that this blocking prevents. The server-side nature means there is zero workaround available.

View original on GitHub ↗

11 Comments

github-actions[bot] · 5 months ago

Found 2 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/38378
  2. https://github.com/anthropics/claude-code/issues/33344

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

eched1 · 5 months ago

Any updates on this?

inninn1012 · 5 months ago

hope can put
wing.coupang.com
into allow list

mikestl · 4 months ago

Same I'm a small business owner who has spent hundreds of hours using Claude Code + Claude-in-Chrome for bookkeeping automation: downloading bank statements, reconciling transactions, navigating banking portals. This is core business infrastructure, not casual use.

The blocking appears to be new (or newly enforced). These workflows were working before and are now broken with no workaround.

mikestl · 4 months ago

I'm on a Teams Premium plan using Claude Code (v2.1.101) with the Claude in Chrome extension (v1.0.66) on macOS. As of the past few days, every single domain is blocked when Claude Code tries to navigate via the Chrome bridge. Every navigation attempt returns "Navigation to this domain is not allowed" — including Wikipedia, GitHub, Google Docs, and dozens of other sites I've tested.

This was working perfectly a few days ago with no changes on my end.

What I've tried:

Verified Organization settings → Claude in Chrome → "Allow extension" is enabled with "works everywhere except blocked sites" — no sites are blocked
Checked the extension's Settings → Permissions → "Your approved sites" — shows "No sites have been approved yet" with no option to add sites
Approved Wikipedia through the side panel cowork flow — still blocked for Claude Code
Fully restarted Chrome (Cmd+Q and reopen) multiple times
Completely uninstalled and reinstalled the Chrome extension
Updated Claude Code from 2.1.92 to 2.1.101
Verified the native messaging host config is intact
The org admin settings are correctly configured to allow all sites, but the Claude Code bridge connection still gets "Navigation to this domain is not allowed" for every domain. The extension's side panel (cowork mode) site approval doesn't carry over to the Claude Code bridge either.

This appears to match GitHub issues #41034 and #40173.

This is a critical workflow for my business — I use Claude Code's Chrome automation daily for construction bid processing, document downloads, and web data extraction.

Could you please investigate why the org-level "Allow extension" setting isn't being respected by the Claude Code bridge?

jeremygregg · 4 months ago

+1 on this issue. I'm a Max plan subscriber using Cowork mode to manage several WordPress sites hosted on GoDaddy Managed WordPress. The Claude in Chrome extension works perfectly on two of my domains but gives "Permission denied for this action on this domain" on a third — a personal blog with no financial, adult, or otherwise sensitive content. All three sites are on the same hosting account, same WordPress version, same SSL setup.

I've confirmed:

  • SSL is active and valid
  • The tab is in the correct Claude tab group
  • The extension has full access permissions in Chrome
  • The domain is not in any blocked category I can identify (it's a personal blog about philanthropy and writing)

The block appears to be a false positive in the server-side domain classification API. I filed a support ticket but the AI chatbot only offered generic troubleshooting (check permissions, refresh the page) that doesn't apply to a server-side block.

What would help:

  1. A way for users to request domain reclassification through support (with a human reviewer, not the AI bot)
  2. A local allowlist so site owners can override false positives for their own domains
  3. Transparency about what triggers a domain to be classified as blocked — right now it's a black box

This is a significant limitation for anyone using Cowork to manage multiple websites. If the extension works on some domains but silently blocks others with no clear reason and no override, it undermines trust in the tool.

450188881-arch · 4 months ago

Adding a real-world use case from Chinese e-commerce:
I'm using Claude Cowork (desktop app) to automate daily inventory and sales reporting for my e-commerce business. The blocked domain is wsgjp.com.cn — the official server for 管家婆网店ERP (Guanjiapo ERP), one of the most widely used ERP platforms among Chinese SME retailers (tens of thousands of active business users).
Blocked URL: https://d4bfunemain.wsgjp.com.cn/Main.gspx
Use case: Automating daily export and analysis of inventory status reports and sales data — a core business workflow.
All Claude in Chrome tool calls (find, read_page, navigate) immediately return:

"This site is blocked by your organization's policy."

This is a completely legitimate business tool with no financial transaction or sensitive data risk. The server-side domain classifier appears to be over-blocking Chinese business SaaS domains as a category, which significantly limits Cowork's utility for Chinese business users.
Request: Please consider either whitelisting wsgjp.com.cn specifically, or adding a user-configurable domain allowlist so business users can unblock trusted domains themselves.

markushausammann · 4 months ago

Our hosting partner Upsun.com uses .site for staging infrastructure, this is also blocked, which makes no sense whatsoever! Please unblock!

AutomatedTradingOz · 3 months ago

It's a real shame as I need it to reconcile my credit card statements and I cannot use it to download my credit card statements from AmericanExpress.com

May have to investigate using OpenClaw with ChatGPT unfortunately.

jigawho-ship-it · 3 months ago

Please allow the user to go add sites that they want to use claude in chrome for. This is breaking my small business project and work that I had spent hundred of hours building. All of a sudden majority of my workflow is stranded due to some arbitrary appearing Claude in Chrome Domain block instituted by Anthropic. Please - please fix this ASAP.

AminDhouib · 2 months ago

We ran into similar domain-blocking issues and ended up building an MCP server that uses a real Chrome instance via nodriver. Since it runs as a separate browser process, domain restrictions in the built-in fetch do not apply.

https://github.com/DevinoSolutions/stealth-chrome-devtools-mcp

Showing cached comments. Read the full discussion on GitHub ↗