Browser pane: no way to trust private-network origins — per-action prompts and blocked subresources on LAN-resolving HTTPS sites

Environment

• Claude Code 2.1.239, desktop app, macOS (darwin 25.6)
• Self-hosted HTTPS sites on public DNS names that resolve to private RFC1918 addresses (split-horizon / LAN-hosted, e.g. https://acms.cnctr.xyz → 10.x.x.x), served with valid TLS via a reverse proxy

Behavior (started after a recent app update)

When the built-in Browser pane (preview browser) opens one of these sites:

1. The pane shows "Site-level permissions are disabled for this site. You'll be asked for each action." — the site-level "always allow" affordance is unavailable.
2. Every click / keystroke / form input triggers a permission prompt, even with the "allow all browser actions" preference enabled and mcp__Claude_Browser allowed in permissions.allow.
3. Page subresources are blocked client-side (net::ERR_BLOCKED_BY_CLIENT): CSS, JS, and images of the site fail to load, so a perfectly healthy app renders broken inside the pane (the same URLs load fine via curl and in regular browsers, and even in the pane when navigated to directly as a top-level document).
4. The classification is recorded in claude_desktop_config.json under preferences.launchPreviewPrivateNetworkReadOrigins / launchPreviewPrivateNetworkReadPins, but these are derived state — removing them and restarting just re-pins the origins from DNS.

Sessions from the previous day drove the same site's admin UI in the pane without any of this, so the gating appears to have shipped in a recent update. Neither the settings reference nor the changelog documents it (checked 2026-08-25).

Why this hurts

Self-hosted/homelab users run their own production apps on LAN-resolving domains. Claude Code is exactly the tool driving those admin UIs (deploy verification, interactive testing), and the pane is now unusable for them: the operator has to click "allow" for literally every action, and the page renders without its own CSS/JS. There is no way to express "I own this origin, trust it fully."

Request

An explicit, user-controlled trust affordance for private-network origins in the Browser pane — any of:

• a site-level "always allow" option that works for private-network origins (per-origin opt-in, ideally with the resolved-IP pin retained so DNS rebinding is still caught), or
• a supported settings key (e.g. launchPreviewPrivateNetworkTrustedOrigins) users can set deliberately, or
• at minimum, stop blocking same-origin subresources on a site the user has already navigated to and approved.

I understand the SSRF/DNS-rebinding motivation for defaulting private-network origins to read-only — the pinning approach is sound. The missing piece is only the explicit opt-out for origins the user owns.

Workarounds in use

Driving these sites via Playwright (isolated Chromium) or the Claude in Chrome extension works fine — the friction is only in the built-in pane.