[BUG] Browser pane blocks all subresources from a PUBLIC internet domain with ERR_BLOCKED_BY_CLIENT (same symptom as #87472, but not an RFC1918 address)

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?

Relationship to #87472 (please read first)

#87472 reports the identical symptom in the same component — document 200, every subresource net::ERR_BLOCKED_BY_CLIENT — but scopes the trigger to RFC1918 private-network addresses. This report is not that case, and it contradicts that scoping:

• the affected host is a public internet domain (<my-domain>), not a LAN address
• http://localhost:8081 in the same pane works completely (11.7 MB, all XHR succeed)
• other public domains in the same pane work fine

So either the trigger is broader than private networks, or there are two separate blocks producing the same error. Filing separately for that reason — happy to have it merged if maintainers see one root cause.

---

In the built-in browser pane (Claude Desktop on Windows), navigating to my own site <my-domain> loads the top-level HTML document with 200, but every subresource from that same origin fails with net::ERR_BLOCKED_BY_CLIENT. The single-page app therefore renders only the static splash markup baked into index.html and then freezes there forever.

The exact same URLs load perfectly in a real browser, via curl, and via the WebFetch tool. This looks like a false positive in the server-side domain classification.

This used to work, and stopped some time in the last few weeks.

Environment

• Claude Desktop on Windows 11 Home (build 26200) — built-in browser pane, not the Chrome extension
• Claude Code 2.1.241 (no update prompt is being shown; this is current for the desktop app)
• Personal Max plan, no organization, no managed-Chrome policy
• Affected: <my-domain> and www.<my-domain> — my own site. Public, hosted on a mainstream static host, no auth required to load, an ordinary consumer web app (no financial, adult, or pirated content)

The identical content is fine everywhere else

| How | Result |
|---|---|
| Built-in browser pane | JS bundle ERR_BLOCKED_BY_CLIENT, 0 bytes transferred, frozen on splash |
| Real Edge 151 driven by Playwright (headless) | 200, ~6.4 MB bytes, 0 failed requests, 0 console errors, login screen renders |
| curl | 200, ~4.0 MB bytes, content-type: application/javascript |
| WebFetch tool | page read successfully |

Response headers are unremarkable: 200, access-control-allow-origin: *, server: <static host>, correct content-type, no CSP, no X-Frame-Options.

It targets this one domain, and it is not about domain obscurity

From a CSP-free page (example.com), injecting <img> elements with cache-busting query strings. Every URL below was first verified to return 200 image/png with curl:

| Origin | Loads in the pane |
|---|---|
| t1.daumcdn.net | yes |
| www.google.com | yes |
| raw.githubusercontent.com | yes |
| placehold.co (small, obscure service) | yes |
| dummyimage.com (small, obscure service) | yes |
| <my-domain> | no — ERR_BLOCKED_BY_CLIENT |
| www.<my-domain> | no — ERR_BLOCKED_BY_CLIENT |

Obscure third-party domains load fine, so this is not a "the domain has no reputation yet" rule — it singles out my domain.

Possibly related over-blocking

In the same pane, https://naver.com — South Korea's largest web portal — is refused outright with This site is not allowed due to safety restrictions, while daum.net (the same category of service) works normally.

Impact

I cannot use Claude to verify my own deployed site. Local dev works, but "does the production build actually run in a browser" is precisely the check that has to happen against the deployed origin, and every other browser on this machine loads it fine.

I spent a long time debugging my own server and application before establishing that neither was at fault, because ERR_BLOCKED_BY_CLIENT on a subresource is indistinguishable from an ad blocker, a server fault, or a broken build.

Requests

1. Re-classify <my-domain> / www.<my-domain> as allowed.
2. Surface the block. Show a visible "this domain is blocked by Claude" notice in the pane instead of a bare network error.
3. Provide some path for a site owner to request review of their own domain.

Related: #87472 (same symptom, private-network scope), #55580 (user-controlled allowlist override — closed as not planned), #58464 (approved sites still blocked), #83742 (all https blocked mid-session).

What Should Happen?

Subresources (JS, fonts, images) from a domain whose top-level document the pane just loaded with 200 should also load, so the page actually runs — the same way every other browser on this machine loads it.

And if the domain genuinely is blocked by policy, the pane should say so visibly, rather than surfacing a bare net::ERR_BLOCKED_BY_CLIENT that is indistinguishable from an ad blocker, a server fault, or a broken deployment.

Error Messages/Logs

read_network_requests on the pane's tab at https://<my-domain> :

GET https://<my-domain>/                                                      -> 200
GET https://<my-domain>/_expo/static/js/web/entry-<hash>.js                    -> FAILED net::ERR_BLOCKED_BY_CLIENT
GET https://<my-domain>/assets/assets/fonts/Font-A.<hash>.otf      -> FAILED net::ERR_BLOCKED_BY_CLIENT
GET https://<my-domain>/assets/assets/fonts/Font-B.<hash>.otf       -> FAILED net::ERR_BLOCKED_BY_CLIENT
GET https://<my-domain>/assets/assets/fonts/Font-C.<hash>.otf     -> FAILED net::ERR_BLOCKED_BY_CLIENT
GET https://<my-domain>/assets/assets/fonts/Font-D.<hash>.otf         -> FAILED net::ERR_BLOCKED_BY_CLIENT
GET https://<my-domain>/assets/assets/fonts/Font-E.<hash>.ttf  -> FAILED net::ERR_BLOCKED_BY_CLIENT

Console:
[error] Failed to load resource: net::ERR_BLOCKED_BY_CLIENT      (x6)

Inside the page:
performance.getEntriesByType('resource')  ->  12 entries, 0 bytes transferred in total

Same origin, same moment, real Edge via Playwright:
  JS bundle 200 / ~6.4 MB bytes / 0 failed requests / 0 console errors / login screen rendered

Steps to Reproduce

1. Open the built-in browser pane in Claude Desktop on Windows.
2. Navigate it to https://<my-domain> (this is my own public domain; no login is required to load it).
3. Observe that the page renders only the static splash markup baked into index.html and never boots.
4. Run read_network_requests on that tab:

• the document request is 200
• every same-origin subresource (one JS bundle, five font files) is FAILED net::ERR_BLOCKED_BY_CLIENT

1. Run javascript_tool on the same tab:

performance.getEntriesByType('resource').reduce((a,r)=>a+r.transferSize,0) -> 0

1. Control A — in the same pane, load any other site that has subresources, e.g. https://ko.wikipedia.org : 36 resources, ~383 KB, loads normally.
2. Control B — fetch the identical blocked JS URL with curl : 200, ~4.0 MB bytes.
3. Control C — load the identical URL in a real browser (I used Playwright driving system Edge, headless): the app boots fully, ~6.4 MB bytes, 0 failed requests, 0 console errors.
4. Control D — from a CSP-free page in the same pane (example.com), inject <img> with cache-busting query strings pointing at several curl-verified 200 image/png URLs. t1.daumcdn.net, www.google.com, raw.githubusercontent.com, placehold.co and dummyimage.com all load; <my-domain> and www.<my-domain> do not.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.241 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_