[FEATURE] Browser pane: allow a persistent grant for interaction on an approved private-network host, not just for reading

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When Claude works against a web application on a private-network host, every interacting call
raises a permission card that has to be confirmed by hand — one card per click, one per scroll —
and there is no way to stop it.

The read side is already solved. The permission card offers "always allow read access on this
host", which is persisted and pinned to the resolved address, and after granting it the read-only
tools run silently. The card states the scope plainly:

This website is on a private network. "Always allow read access on this host" lets Claude use
read-only tools here — page text, screenshots, network requests — without asking every time.

There is no equivalent for interaction. Verifying a change in a running app means clicking
through it, and each of those steps needs a separate confirmation.

Measured on 1.37937.1, one call at a time:

call public site private-network host (approved for reading)
--------------------- ------------- -------------------------------------------
get_page_text no card no card
read_page no card no card
computer (screenshot) no card no card
computer (scroll) no card CARD
computer (left_click) no card CARD

This affects anyone whose development or staging sites live on a server on the LAN rather than on
localhost, which is normal in setups where several sites share one host with name-based virtual
hosts.

Proposed Solution

Add a second persistent grant alongside the existing read grant — offered on the same card, with
the same scope and the same safeguards:

[ Deny ] [ Always allow read access on this host ] [ Always allow on this host ] [ Allow once ]

"Always allow on this host" would cover interacting calls as well as reading, for that origin
only, and would be pinned to the resolved IP address exactly as the read grant already is, so the
protection against DNS rebinding is unchanged. It should be revocable in the same place as the
read grant.

The point is not to loosen the private-network protection. It is that a user who has already made
a deliberate, informed decision about a specific host currently cannot express "and I mean
interaction too".

Alternative Solutions

Everything available on the user's side has been tried and measured, and none of it helps:

HTTPS on the internal host Own CA, certificate for the internal name, CA installed in the
Windows trust store. The Browser pane accepts the certificate.
The card still appears and still says "private network".

A different hostname An A record under a public domain, pointing at the private
address. Same card, and the origin is pinned to the same
private address — so the classification is made on the resolved
address space, not on the name.

The "Allowed sites" list Adding the host there does not affect these prompts.

The only remaining route is to move the host into the local address space with an SSH port
forward to localhost. That defeats name-based virtual hosts — the forwarded request carries
Host: localhost, so the server answers with the wrong site — and is not practical for a host
serving several sites.

The current workaround is therefore to confirm every card by hand.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

A typical session: Claude changes a template of a web application, then verifies the change in the
running site. The site is served by a server on the LAN, reachable as an internal hostname.

1. Claude opens the page in the Browser pane (covered by the read grant)
2. reads the rendered page (covered)
3. takes a screenshot to compare (covered)
4. clicks a menu entry to reach the affected view -> permission card
5. scrolls down to the changed section -> permission card
6. reads the page text again (covered)
7. clicks a second link to check a related page -> permission card

Steps 1 to 3 and 6 run without interruption. Steps 4, 5 and 7 each stop and wait. In a longer
verification pass this repeats for every step, and the same host is confirmed over and over.

Additional Context

Related: #86384, which reported that a listed private-network host raised a card on every tool
call including read-only ones. That is fixed as of 1.37937.1 and the issue is closed — the read
grant introduced there works as described. This request is the remaining half, and it was raised
as a follow-up question on that closed issue, where it is unlikely to be seen.

The two config keys the read grant uses:

"launchPreviewPrivateNetworkReadOrigins": [ "http://app-c.intranet.example", … ]
"launchPreviewPrivateNetworkReadPins": { "http://app-c.intranet.example": ["192.168.0.10"] }

The naming suggests the read-only limitation is deliberate rather than accidental, which is why
this is a feature request rather than a bug report.

Environment: Claude Desktop 1.37937.1 (MSIX), Windows 10, Claude Code 2.1.246, permission mode
Auto. Host names and addresses above are placeholders.