[BUG] Site permissions ("Allow all websites") ignored by the built-in browser in Claude Code Desktop

I hit a variant of this in Cowork (Claude Desktop). My session-level browser settings were already "all websites allowed" with "network egress" on, but the built-in browser pane still refused every navigation outright — not a per-action dialog, but a hard failure: https://docs.claude.com, and even https://wikipedia.org all failed with "blocked by policy" — a blanket failure, not domain-specific.

Only after I went to Settings → Claude in Chrome → Site permissions and switched the default from "deny all" to "allow all" (a setting I'd never touched, since I don't use Claude in Chrome) did navigation start working (after a restart of Claude Desktop). Still, I had to manually accept every domain after being prompted, but at least it now doesn't block all sites outright.

This suggests that the built-in browser is reading its permissions from the Claude in Chrome site-permission store rather than (or in addition to) whatever the Cowork/session-level "allowed websites" toggle sets. Since the two settings surfaces look unrelated in the UI, a user who has never opened Claude in Chrome has no reason to know that page's default is silently gating the built-in browser too, and will just see the built-in browser as broken/blocked with no visible cause.

Environment: Claude Desktop 1.46388.3, Cowork mode, Windows 11 pro.

Also reproduced on Windows (Claude Code Desktop, latest build), against a private-network origin (http://192.168.0.77:5678, self-hosted n8n instance). Every action — navigate, click, type — triggers the same dialog with only two options: "拒否" (Deny) / "一度だけ許可" (Allow once). No "always allow" choice is offered anywhere in the dialog, regardless of the "Allow all websites" setting under Settings → Claude in Chrome → Website permissions. Confirms this isn't OS- or site-specific — happens the same way on private/internal IPs as on local dev domains.

I am also running into this in Windows 11 against a local IP on my same network. Trying to debug it with Claude and adding the IP to the allowed list in the built-in browser did not fix it.

Same exact issue Claude Code Desktop on MacOS. Was thinking it had something with my *.test local domain. Extremely annoying, cannot let Claude test anything now directly.

Adding a real-world use case: I use the Claude desktop app's built-in browser to automate a 3D printer's local web UI (Mainsail/Moonraker on a LAN IP, plain HTTP). Every JavaScript execution prompts with 'Site-level permissions are disabled for this site. You'll be asked for each action' — even after granting site permission in the dialog, and with the browser MCP tools allowed in settings.json. Local-network automation like this generates dozens of prompts per session, which makes the workflow nearly unusable.

I can reproduce this on Windows with Claude Code Desktop and a Laravel Herd local development domain.

Local frontend:
http://tennispadeljobs.test:3001

My current Claude setting is:

Settings → Claude in Chrome → Site permissions
Default for all sites: Allow all sites
Blocked sites: none

The settings page explicitly states:
"These permissions apply to Claude in Chrome and the built-in browser in the Claude desktop app."

Despite this, the built-in Browser pane repeatedly shows:

"Allow Claude to access tennispadeljobs.test?"
"Site-level permissions are disabled for this site. You'll be asked for each action."

There is no persistent "Always allow" option available in the prompt.

I have a screenshot showing "Allow all sites" enabled and an empty blocked-sites list while this behavior occurs.

So this also reproduces on Windows and with a custom .test hostname used for Laravel local development.

Some findings from chasing this on Windows, in case they save others time. Still present in Claude Desktop 2.2553.1 (2026-09-18), verified against the running package rather than just the installed one.

The "Allow all websites" setting is not what gates this. For hosts that resolve to an RFC1918 address, the built-in browser applies a separate private-network check. That is why changing the Chrome-extension permission, adding the host to "Allowed sites", or setting the folder permission mode makes no difference — none of them touch that check.

There is a grant that works, but only for reading. The card offers "always allow read access on this host". Taking it silences get_page_text, read_page and screenshots permanently; it is stored in launchPreviewPrivateNetworkReadOrigins and pinned to the resolved IP. Interaction has no equivalent, so clicking, scrolling and typing still raise one card per call. If you are only reading pages, that button solves it today.

No workaround exists on the user's side. Measured, each ruled out: HTTPS with a certificate from an own CA trusted by the OS; a hostname under a public domain pointing at the private address; the "Allowed sites" list. The classification follows the resolved address space, not the name or the scheme. A reverse proxy on a public address does avoid it, which fits the same explanation.

If your host resolves to loopback (for example Herd's *.test), that is a different address space and a different report — see #92698.

The request for a persistent interaction grant is #90305 and #89656. And a note on the 2.2553.0 changelog entry about private-network sites "loading without their styles, scripts, or data": that fixes subresource loading, not these prompts. The two are separate, and it is easy to read the entry as covering both.

Same behaviour here, with the site explicitly listed in Settings → Browser → Allowed sites, not only "Allow all websites".

• Claude desktop app 2.2553.1 (Code tab), Claude Code CLI 2.1.270 (Claude Code), macOS 26.3
• Site: http://constructor-cms.test (Laravel Herd, .test TLD, plain HTTP)
• constructor-cms.test is in the Allowed sites list (Settings → Browser → Allowed sites shows it), yet every built-in browser navigation to it shows:

Allow Claude to access constructor-cms.test? Site-level permissions are disabled for this site. You'll be asked for each action. { "origin": "http://constructor-cms.test" }

with only Deny / Allow once, so "Always allow" is never offered and the allow-list entry is ignored. Other .test hosts in the same list (wmd-portal.test, wmd-helpdesk.test) behave the same way. Public hosts in the list (e.g. brinje.info) do not prompt.

Expected: an origin present in Allowed sites should not prompt per action, or the dialog should say why local TLDs are excluded and how to opt in for a dev host.

Also running into this on Claude Desktop's built-in browser — same symptoms exactly:

• Settings → Claude in Chrome → Website permissions is set to "Allow all websites", block list empty
• Every javascript_tool call still pops "Allow Claude to execute JavaScript on <site>?" with "Site-level permissions are disabled for this site. You'll be asked for each action."
• Restarting the app / re-saving the setting doesn't help

This is seriously hurting my daily work: any task involving the built-in browser needs dozens of manual approvals per session, which defeats the purpose of the permission setting entirely.

Could you please raise the priority on this and ship a fix soon? Happy to provide logs or extra repro details if needed.

Environment: Claude Desktop [16e20e], [macOS 27.0]

Re-tested on 2.7032.0 (2026-09-22): unchanged. For private-network hosts, reads stay silent once the read grant is taken, but every click and every scroll still raises its own card. Same on 2.2553.1 and 1.37937.1 before it.

Have the same issue on Windows, Claude 2.9939.2 (d3e504)

Seeing the same thing on macOS, Claude Desktop Code tab, with mcp__Claude_Browser__get_page_text (not just javascript_tool), so this isn't limited to one tool.

Prompt text: "Allow Claude to read page content on <site>? Site-level permissions are disabled for this site. You'll be asked for each action."
The site is on the pane's own list (⋯ → Manage allowed sites), and it's a local dev host (http://srom-divi5.local). Adding it there doesn't stop the prompts.
Navigation to the site succeeds without a prompt. Reading page content and clicking still prompt each time.
Adding mcp__Claude_Browser__* to permissions.allow makes no difference, since the prompt comes from the site layer, not tool permissions.
The pane's "Auto-verify changes" toggle also doesn't persist between sessions.

No workaround found. Falling back to curl/CLI for non-visual checks. Happy to provide more detail if useful.

+1 super blocking in any kind of workflow.... absolutely destroys the UX

Same here, on Claude Code in the desktop app, with a local dev site at https://next.test (served by lerd, resolving to 127.0.0.1, with a trusted mkcert certificate). The permission mode is bypass permissions, yet every built-in browser call, even just reading page content, shows "Site-level permissions are disabled for this site. You'll be asked for each action." The only buttons are Allow once and Deny, and approvals never stick, so a single debugging session means clicking Allow once over and over.

Previewing my local dev site is the main reason I'd use the built-in browser in Claude Code, and .test is the TLD reserved for exactly that (RFC 6761). The Claude in Chrome extension handles the same site fine. Please let users grant standing permission for local dev hosts, or honor Allowed sites and "Allow all websites" for them.

+1 same issue here with .test local dev sites, super annoying and destroys the experience.

plus one here, exhausting experience.

I tried all combinations of settings, but it's clearly a bug in Claude Code. Sometimes it works but most of the time it doesn't.

The fact that you can add domains with and without www. and that the UI doesn't distinguish between the two indicates to me that not the developers have been a little sloppy when it comes to managing site permissions.

My solution for now is to use Codex. That never has these issues.

very annoying bug

Same issue here on Windows 11 with Claude Desktop 2.31226.1 (857652, built 2026-10-09), so it's still present in the latest build.

My case: a public domain name, nxgen.ru, which resolves to a private IP on my network.

• Settings → Claude in Chrome → Website permissions: "Allow all websites", blocked sites empty
• Built-in browser still shows a permission prompt on every action

("Website permissions are disabled for this website. You will be asked for every action.")

• No persistent "always allow" option for interactions

This matches @level420's finding: the private-network check kicks in based on the resolved IP, not the hostname. So even a regular public domain name gets gated if it resolves internally (split DNS, hosts entry, internal network), and the "Allow all websites" setting has no effect on it.

It would help to have either a persistent "always allow interactions on this host" grant, or to have "Allow all websites" / the allowed-sites list also cover private-network hosts.

I don't recall seeing these prompts in earlier versions, but I can't pin down when it started.