Built-in browser: no "Always allow" for actions on private-network hosts; every click asks for approval (contradicts docs)

Environment

• Claude Desktop (Windows), package version 2.37337.1.0
• Windows 11 Pro 10.0.26200
• Code tab, permission mode: Bypass permissions
• Built-in browser, Keep cookies: Shared

Summary
On a host that resolves to a private IP address, I can save "Always allow" for navigation and for reads. I cannot save it for actions. Every click by Claude shows an approval card with only "Allow once" and "Deny". The card says: "Site-level permissions are disabled for this site. You'll be asked for each action."

Steps to reproduce

1. Use an internal HTTPS host, for example https://app.example.local, that resolves to a private address (192.168.x.x).
2. In a Code session, ask Claude to open the site in the built-in browser.
3. On the "Allow Claude to act on …?" card, choose Always allow.
4. On the "Allow Claude to access …?" card, choose Always allow reads on this host.
5. Add the site under Settings → Claude Code → Browser → Allowed sites.
6. Ask Claude to click an element on the page.

Expected result
After step 3, Claude can click and type on the site without a prompt. The docs say: "For a site on your private network, Claude Desktop still asks before each action until the user chooses Always allow for that site."
(https://claude.com/docs/third-party/claude-desktop/browser)

Actual result

• Navigation and reads work without a prompt.
• Every click shows the card "Allow Claude to click on app.example.local?" with the text "Site-level permissions are disabled for this site. You'll be asked for each action." The card has no "Always allow" option.
• Bypass permissions mode does not change this result.

Local config observation
%APPDATA%\Claude\claude_desktop_config.json contains the host in:

• preferences.launchPreviewAllowedOrigins (navigation)
• preferences.launchPreviewPrivateNetworkReadOrigins and launchPreviewPrivateNetworkReadPins (reads, pinned to the private IP)

The config has no key that stores an action grant for a private-network host. So the app cannot persist "Always allow" for actions on these hosts.

Impact
We test internal applications on a private test network. Each click needs a manual approval, so Claude cannot run a UI test without supervision.

Related

• #78315 reports the same pattern: read and interact actions on private or loopback hosts ask per action, although the site is in "Allowed sites". A bot closed it as "not planned" and locked it, without a maintainer reply. Users reported it on Windows, macOS and Linux.

Request
Allow "Always allow" for actions on a private-network host, as the docs describe. Alternatively, document the restriction and provide a setting for it.