Desktop app browser pane blocks subresources of sandboxed (null-origin) iframes with ERR_BLOCKED_BY_CLIENT

Summary

In the Claude desktop app's built-in browser pane, a page from an allowed site embeds an iframe served with Content-Security-Policy: sandbox allow-scripts (no allow-same-origin), so the frame document has an opaque null origin. The frame HTML loads, but every subresource it requests (app.js, app.css, a stylesheet from the parent's own origin) fails with net::ERR_BLOCKED_BY_CLIENT. The same page works in Chrome.

The pane appears to match request initiators against its per-site allowlist; a null initiator origin matches nothing, so the requests are dropped even though the top-level page and the target origins are both allowed.

Steps

1. Serve http://a.localhost:8080/ with <iframe src="http://b.localhost:8787/frame/">.
2. Serve /frame/ with Content-Security-Policy: sandbox allow-scripts; frame-ancestors http://a.localhost:8080 and <script src="./app.js"></script>.
3. Open http://a.localhost:8080/ in the pane and allow both sites when prompted.
4. read_network_requests: the frame document is 200, app.js is [FAILED: net::ERR_BLOCKED_BY_CLIENT]. Loading /frame/ top-level in the pane shows the same: document 200, subresources blocked.

Expected

Subresource requests from a sandboxed frame whose top-level page is an allowed site should be allowed, the same as the top-level page's own requests. CSP sandbox without allow-same-origin is the standard way to isolate untrusted embedded code; blocking it makes the pane unusable for any product that previews user-generated apps in an isolated frame.

Environment

Claude desktop app (macOS, Darwin 27.0.0), Code tab, built-in browser pane, 2026-09-21.