The browser is a peripheral

I use the browser tools in Claude Code most weeks, usually for the boring end of the job: check that a deploy actually rendered, read a console error out of a page that only breaks when logged in, fill a form I do not want to fill again. It works well enough that I had never asked what happens in between. Then somebody asked me and I found I could describe the capability and not the mechanism, which is the tell that I had been reading documentation instead of the thing.

Five hops to a click

The useful reframing is in the title. The model is not in the browser and does not reach into it. It emits a tool call, the same shape as any other tool call, and something downstream turns that into a click. The browser is a device on the end of a wire.

model
 └─ read_page / computer / navigate ...
     └─ chrome tool server   # in-process, inside the CLI. not a subprocess
         └─ wss://bridge.<vendor-relay>/chrome/<account>   # leaves the machine
             └─ extension service worker   # MV3, host_permissions <all_urls>
                 ├─ content script: accessibility-tree.js
                 └─ chrome.debugger   # clicks, typing, screenshots
                     └─ the page

Two details in there are worth pulling out. The tool server runs inside the CLI process, not as a child of it: the session log says In-process Chrome MCP server started and then reports a stdio transport connecting in four milliseconds, which is an in-memory pair, not a pipe.1 And the content script is injected at document_start, in every frame, on every URL. Nothing about that is unusual for an extension of this kind, but it is the answer to “when does it start looking”: before your page runs.

How a page becomes something a model can read

There are two channels, and they are not interchangeable.

The structured one returns an accessibility tree with opaque reference tokens, ref_0, ref_1, and so on. It is capped: fifteen levels deep, ten thousand elements, fifty thousand characters. Password fields and hidden inputs come back as a redaction marker rather than a value. A second tool skips the tree and walks ten content selectors in priority order, first match wins, falling back to the whole body.

The visual one returns a screenshot as a short text handle plus a separate base64 image block. Across my own transcripts those ran from about three kilobytes to a hundred and sixty-seven, almost always JPEG.

The reference system is the interesting design choice, and I think it is the right one, because the coordinate story does not hold up. Going back over eighty-one annotated screenshots in my own sessions, twenty-eight had a delivered width that did not match the scale the annotation itself declared. The same “0.6 scale” label produced ratios of 0.600, 0.667 and 0.800 on different captures.2 The screenshot frame is also not reliably the same as the viewport the structured read reports. If you are wiring these tools into anything you intend to trust, prefer a reference over a coordinate wherever the tool offers both. Pixels are a fallback, not a foundation.

Where the page actually goes

This is the part I did not expect, and the part I got wrong on the first pass before checking it properly.

I assumed the browser was driven locally. There is every reason to think so: the CLI registers a native messaging host with seven different browsers, and a matching helper process really does sit there holding a unix socket with private permissions, one per process id. That machinery exists, it works, and the code that would encrypt payloads end to end lives on exactly that path.

It is not the path the CLI uses. The transport selector checks for a bridge configuration first, and the factory that builds the context sets that configuration unconditionally, so the websocket branch always wins and the local socket pool is unreachable from this client. It also never sets the options that would turn on the sealing, the proactive dialing or the peer-credential check. On my machine the live socket has exactly one holder, the desktop app’s helper, and nothing connected to it. Two transports exist. Which one you are on depends on which client you are running, and the answer for the command line is the remote one.

So the frame goes out over a websocket to a vendor-hosted relay, addressed by account, authenticated by an access token in the opening message. Tool calls and their results are matched by a request id. And the sealing does not apply: every reference to it in that module sits in the local-socket pairing code, none in the websocket client, which builds its frame and serialises the arguments as they are. Page text, accessibility trees and base64 screenshots cross as clear JSON inside TLS to a machine that is not yours.

I read that out of the binary rather than off the wire, so treat it as a strong code-level claim and not a packet capture. It is also not a vulnerability and I am not presenting it as one. TLS is doing its job and the relay is the vendor’s own. But it does change the answer to a practical question, which is which tabs you point this at. “The agent reads the page locally” would have been a reasonable thing to assume and it is not what happens.

What is actually watching

Everything on the return path is written by the page. Not just the obvious text and screenshots, but the console, the network bodies, the tab titles and URLs appended to nearly every result, and, my favourite, the confirmation string after a form fill, which helpfully echoes the field’s previous value. A hostile page controls all of it.

There are gates, and they sit in different places: per-site grants and blocked categories inside the extension, an approval mode with a classifier that inspects each outgoing call, and account identity on the connection itself. Documented protected actions still interrupt even on a site you have blanket-approved, and a documented prohibited list refuses outright, including the nicely circular entry for completing instructions found in web content.

The gap worth naming: nothing in the command-line binary inspects the content coming back. The probes that scan tool results for injections are real and documented, but they are not in this artifact, which carries one generic warning sentence in the system prompt and a classifier pointed at the outgoing call. That layer lives elsewhere, server side or on another surface. If your mental model was “something on my laptop is checking the page before the model reads it”, that is not what I found.

The published robustness numbers deserve the same care. There are at least four separate evaluations across about a year: an early suite of a hundred and twenty-three cases, an adaptive best-of-N attacker, a harness the vendor retired because it had been saturated, and a current red-team suite. The grader changed. The denominator changed to attacks that reached the model. Quoting the early figure and the current one as a single trend line would be wrong, which is the same provenance problem I wrote about in the closed frontier: the number is fine, the comparison is the thing that breaks. The vendor’s own framing is the honest one, that a low single-digit success rate still represents meaningful risk.

If you are about to use it

Prefer references over pixel coordinates. Treat every returned string as untrusted input, including the ones that look like the tool talking rather than the page. Assume the content of any tab you open leaves the machine. And keep a separate browser profile for it, which is the vendor’s own recommendation and the cheapest control available.

The honest close is the limit rather than the finding. The command-line half of this I can stand behind, because I read the running artifact and its own logs. The browser half I read from a store download, because the operating system would not let me open the copy that is actually running. Two halves of one system, described at two very different confidences, and the one users care about is the weaker one. If somebody can read the installed bundle on a machine without that restriction, the in-page mechanism is where I would look first.