Browser tool "read tools" per-action approval doesn't respect launchPreviewAllowedOrigins / "Allowed sites" list
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:
- Add a self-hosted domain (e.g. a private homelab service on a custom domain) to Settings → Allowed sites → Add URL.
- Navigate the Browser pane to that URL — this succeeds and loads the page.
- Attempt a screenshot or
get_page_textaction — this fails with the per-action approval error, even in a fresh tab, even after the domain is confirmed present inlaunchPreviewAllowedOriginsinclaude_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.
Showing cached comments. Read the full discussion on GitHub ↗
7 Comments
Closing for now — this doesn't appear to be about Claude Code. Please open a new issue if this is still relevant.
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.
Exactly the same error as described by @lscheibel. Using Claude Code on MacOS.
We have many
.testdomains that are blocked, even when all the domains are defined in the allow list.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 literallocalhostis exempt which is how i was able to find a workaround by making the app reachable vialocalhost:<port>origin.Also this functionality works as expected in Codex, so maybe this will move it higher priority :)
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.
Also hitting this exactly on macOS. My case:
lvh.mesubdomains (<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 to127.0.0.1, not literallylocalhost). Navigation viapreview_start/navigatesucceeds and the domain shows up correctly under "Allowed sites," but every read tool (read_page,get_page_text,computerscreenshot) 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 oflaunchPreviewAllowedOrigins, as others found here.Same here:
Huge pain