Browser tool "read tools" per-action approval doesn't respect launchPreviewAllowedOrigins / "Allowed sites" list

[strickdd]

When using Claude Desktop's Browser pane, navigation (preview_start/navigate) to a domain listed in Settings → "Allowed sites" succeeds without a prompt, but the separate read/interact actions (screenshot, get_page_text, read_page, click/type) still fail with:

"This site requires per-action approval; Browser read tools are not available on it."

Steps to reproduce:

1. Add a self-hosted domain (e.g. a private homelab service on a custom domain) to Settings → Allowed sites → Add URL.
2. Navigate the Browser pane to that URL — this succeeds and loads the page.
3. Attempt a screenshot or get_page_text action — this fails with the per-action approval error, even in a fresh tab, even after the domain is confirmed present in launchPreviewAllowedOrigins in claude_desktop_config.json.

Contrast: well-known public domains (e.g. example.com) and other custom domains with more public presence (e.g. our own project's stage subdomain) work with zero prompts and no allowlist entry needed at all. Several self-hosted domains under a private/low-traffic domain remained blocked despite explicit "Allowed sites" approval.

Investigation: I checked ~/.config/Claude/claude_desktop_config.json and confirmed the blocked domains are present in preferences.launchPreviewAllowedOrigins. No other local config file (config.json, Preferences, LevelDB Local Storage) contains a separate allowlist for the read-tools gate, suggesting this second gate is enforced server-side independent of the local "Allowed sites" setting — which is not what the settings UI implies ("Claude can use its Browser tools on these sites without a permission prompt").

Expected: Adding a site via "Allowed sites" → Always allow should unlock both navigation and read/interact actions.

Environment: Claude Desktop running via distrobox on Bazzite (Fedora Atomic) Linux.

[github-actions]

Closing for now — this doesn't appear to be about Claude Code. Please open a new issue if this is still relevant.

[lscheibel]

Same thing happening on macOS.

localhost, example.com, etc are fine but custom loopback addresses like example.test mapped to 127.0.01 through /etc/hosts will fail with the error message: "This site requires per-action approval; Browser read tools are not available on it.". The domain is listed in "Allowed sites" and there is no way to unblock.

[GregoireGaonach]

Exactly the same error as described by @lscheibel. Using Claude Code on MacOS.

We have many .test domains that are blocked, even when all the domains are defined in the allow list.

[cagansevencan]

same as @lscheibel also using macOS. Allowlisted custom domains that resolve to 127.0.0.1 load fine via navigate, but every read/interact tool refuses with "requires per-action approval". Only literal localhost is exempt which is how i was able to find a workaround by making the app reachable via localhost:<port> origin.

Also this functionality works as expected in Codex, so maybe this will move it higher priority :)

[strickdd]

Just for a little more clarification, some of mine resolve to 127.0.0.1 and some resolve to 172.16.65.x (internal network) IPs.

[bobbygeo]

Also hitting this exactly on macOS. My case: lvh.me subdomains (<tenant-slug>.lvh.me:3000) used for local multi-tenant dev testing — same category as the .test/loopback domains reported above (a real public DNS name that resolves to 127.0.0.1, not literally localhost). Navigation via preview_start/navigate succeeds and the domain shows up correctly under "Allowed sites," but every read tool (read_page, get_page_text, computer screenshot) fails with "This site requires per-action approval; Browser read tools are not available on it." No approval prompt ever appears to clear it, and re-approving the site in the allowlist doesn't help. Confirms the gate is enforced independent of launchPreviewAllowedOrigins, as others found here.

[kobykorman]

Same here:

• Claude Code Desktop
• MacOS
• x.test in allowed sites list
• Every non-navigation action on it requires my confirmation

Huge pain

[deg026]

Same here:
Claude Code Desktop / Windows 10 Pro
local CRM system at www.rp.local in allowed sites list
All read content action requires manual confirmation
it is really killing me