[BUG] Browser pane: the private-network read grant does not cover find, zoom, scroll, hover and read_console_messages, although the app files them as read requests

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On a private-network host the permission card offers "Always allow read access on this host".
After it is taken, get_page_text, read_page and screenshot run without a card, as the card says.

Five more tools do not, although the app itself files them as read requests. The log entry for
each is "cat3 per-action read approval requested", the same category as screenshot. After the
grant they still raise a card on every call, and that card never offers the grant
(offerAlwaysGrant: false). There is no way to stop them:

find
read_console_messages
computer: zoom
computer: scroll
computer: hover

None of them changes the page. zoom returns a crop of what screenshot returns, and find searches
the same tree that read_page returns. Yet screenshot and read_page are covered, and zoom and find
are not.

Counted from the app's own log, from 1.37937.1 (when the read grant was introduced) to today,
across all sessions, on private-network hosts that are all in
launchPreviewPrivateNetworkReadOrigins:

tool cards card offers the grant
--------------------- ----- --------------------------------------------------
get_page_text 5 yes, on first contact with a host; silent afterwards
screenshot 8 yes, on first contact with a host; silent afterwards
read_page 0 -
find 101 never
read_console_messages 38 never
zoom 14 never
scroll 11 never
hover 7 never

That is 171 cards, each confirmed by hand, for tools the app classes as read.

What Should Happen?

The read grant should cover every tool the app itself classifies as read. At the very least it
should cover zoom and find, which return a subset of what screenshot and read_page already
return without a card.

If some of these are excluded on purpose, the card should offer a way to stop asking for them,
and the grant's description should say which tools it covers. It currently says "read-only
tools (page text, screenshots, network requests)", which a user reasonably takes to include a
zoomed screenshot.

Error Messages/Logs

From %LOCALAPPDATA%\Claude\Logs\main.log on 2.7032.0. Request and session IDs replaced by
placeholders.

A controlled run, one call at a time, on a host that has held the read grant since 2026-08-26:

    preview_start http://app-c.intranet.example    no log entry, no card
    get_page_text                                  no log entry, no card
    read_page                                      no log entry, no card

    computer left_click                            card, filed as interaction:

      [Preview] cat3 per-action approval requested {
        origin: 'http://app-c.intranet.example',
        toolName: 'computer',
        action: 'left_click'
      }
      Emitted tool permission request <id> for browser:left_click in session local_<session>

    computer scroll                                card, filed as READ:

      [Preview] cat3 per-action read approval requested {
        origin: 'http://app-c.intranet.example',
        toolName: 'computer',
        offerAlwaysGrant: false
      }
      Emitted tool permission request <id> for browser:scroll in session local_<session>

The same on a second host (HTTPS, trusted certificate), from ordinary work:

      [Preview] cat3 per-action read approval requested {
        origin: 'https://app-d.intranet.example',
        toolName: 'find',
        offerAlwaysGrant: false
      }
      Emitted tool permission request <id> for browser:find in session local_<session>
      LocalSessions.respondToToolPermission: requestId=<id>, decision=once

      [Preview] cat3 per-action read approval requested {
        origin: 'https://app-d.intranet.example',
        toolName: 'computer',
        offerAlwaysGrant: false
      }
      Emitted tool permission request <id> for browser:zoom in session local_<session>
      LocalSessions.respondToToolPermission: requestId=<id>, decision=once

For comparison, the first screenshot on that host before the grant existed. It has the same log
message, but this time the card offers the grant:

      [Preview] cat3 per-action read approval requested {
        origin: 'https://app-d.intranet.example',
        toolName: 'computer',
        offerAlwaysGrant: true
      }
      Emitted tool permission request <id> for browser:screenshot in session local_<session>

Steps to Reproduce

1. Serve any page from a host with a private (RFC1918) address, e.g.

http://app-c.intranet.example.

1. Open it in the Browser pane with preview_start. On the first read-only call the card offers

"Always allow read access on this host". Take it.

1. Call get_page_text, read_page and computer screenshot. No card: the grant works.
2. Call find, read_console_messages, or computer with zoom, scroll or hover.
3. Each call raises a card offering only "Deny" and "Allow once". Repeat the call and the card

appears again.

1. In %LOCALAPPDATA%\Claude\Logs\main.log each of these cards is filed as

"cat3 per-action read approval requested" with offerAlwaysGrant: false.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.280

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment

Claude Desktop 2.7032.0 (MSIX), newest release at the time of filing. Present on every
build since 1.37937.1: find, zoom and scroll were seen on 2.7032.0, hover
last on 2.2553.1, read_console_messages last on 2.110.1 (not used since).
OS Windows 10, 10.0.19044
Permission mode Auto
Hosts internal hosts on a private network, over HTTP and over HTTPS with a
trusted certificate; the names above are placeholders

Why this is separate from #90305

#90305 asks for a new grant that covers interaction (click, type). This report is narrower: the
existing read grant does not reach tools the app has already sorted into the read category.
Fixing the mismatch needs no new grant and no new UI.

Scale

Over the same period the log records 2,505 per-action cards on private-network hosts. 2,321 of
them are for interaction (2,003 javascript_tool, 216 left_click), which is the subject of #90305.
The 171 cards above are the ones the existing read grant was meant to remove.

Related: #90305 (grant for interaction), #91495 and #96400 (per-site prompts in general), #79110
(closed; read tools blocked before the read grant existed).