Desktop built-in browser can't grant standing permissions for .local hosts (WordPress Studio sites)
Summary
In the Claude desktop app, every browser action on a local site https://site.local (a WordPress Studio site served from 127.0.0.1) prompts with:
Site-level permissions are disabled for this site. You'll be asked for each action.
Adding the site to Allowed sites doesn't help. The site is present in launchPreviewAllowedOrigins in claude_desktop_config.json, and navigation works, but every click, type, and screenshot still prompts. The "Always allow reads on this host" option is never offered.
Cause
The desktop app's private-host resolver in app.asar returns not-private when the hostname is local, ends with .local, or has no dot (localhost). That path forces _perActionOnly on every request and never sets _privateHostReadAlwaysOffer, so .local hosts can't receive a standing grant even though they resolve to loopback.
WordPress Studio requires custom site domains to end in .local (its bundle enforces "The domain name must end with .local"), so no domain satisfies both tools. Studio's default localhost:<port> is dotless and hits the same exclusion.
Expected
A .local or localhost host that resolves to loopback or a private address should be eligible for the same "Always allow reads on this host" grant as a dotted private hostname, or Allowed sites should suppress the per-action card for it.
Steps to reproduce
- Create a WordPress Studio site and give it a custom domain (Studio only allows
<name>.local). - In the desktop app, start a Claude Code session and have it open the site in the built-in browser pane.
- Ask it to take a screenshot or click anything.
- Observe that every action prompts and no standing grant is offered. Adding the site to Allowed sites doesn't change this.
Environment
- macOS (Darwin 27.0.0)
- Claude desktop app, bundled Claude Code 2.1.271
- WordPress Studio with a
.localcustom domain and HTTPS enabled (Studio CA trusted in the login keychain; the site loads fine in Chrome and curl)
6 Comments
also confirmed same issue on Windows, not platform dependant
Same behavior on Windows 11 with a private LAN IP, not just
.local. Site:http://192.168.0.100:1880(Node-RED dashboard on a Sonoff iHost, LAN only). In the built-in browser pane,navigate,javascript_tooland click actions showed "Site-level permissions are disabled for this site. You'll be asked for each action." and no "Always allow" option was offered. Expected: a private LAN address (192.168.x.x) should be eligible for a standing "Always allow" grant, as the docs describe for external sites. Desktop app on Windows 11, Claude Code Code tab, September 2026.Temp work around is the Claude in Chrome doesn't have this issue, only the Claude desktop browser so if you install the chrome extension and tell Claude to only use the claude in Chrome not the built in browser you at least dont have to sit there and hit yes 1000 times per session
@nickfmc thanks a lot for the tip! I tested it and your workaround works: with the Claude in Chrome extension I can open and read the LAN page (
http://192.168.0.100:1880) without any trouble, so I'm using it instead of the built-in browser for now. The built-in browser behavior is still there, but this makes it perfectly usable in the meantime.This issue is beyond frustrating
Windows 11, desktop app 2.1.269, private LAN IP (same as @djpole). There is a workaround that stops the prompts completely - clicks and typing included - and it explains why the Allowed sites list seems to do nothing.
The button only grants reading. "Always allow reads on this host" does exactly what it says: after taking it, navigation, page text and screenshots stop asking, but every click and keystroke still raises a card saying "Site-level permissions are disabled for this site" - about a site that is now in your Allowed sites list. No button anywhere grants interaction.
Workaround: Settings -> Claude Code -> Browser -> Allowed sites, and add the origin by hand (http://10.0.2.36:83 - one entry per port). That's it. Prompts stop for every tool. I then ran a full session - logging in, clicking through a grid, expanding rows, typing into fields - 27 tool calls, zero prompts. No need to switch to the Chrome extension.
Why the button isn't enough: in claude_desktop_config.json it writes the origin to launchPreviewPrivateNetworkReadOrigins, while adding it by hand writes it to launchPreviewPrivateNetworkTrustedOrigins - and that second list is the one that covers interaction. Tested on a fresh origin in one session: 5 prompts in 10 calls with nothing set, then 0 prompts in 13 calls of the same action types after adding it by hand.