Browser & Visual Verification
Interactive Browser
The agent can open a real browser, click and type through your running app, read the console — and, on vision-capable models, actually see the screenshots it takes. That’s how it verifies that a change works, not just that it compiled.
What it can do
The agent uses a single persistent browser session per workspace and drives it with a set of actions:
- navigate — load a local URL.
- snapshot — read the accessibility tree, with a
[ref]for each element to act on. - click / type / press / scroll — interact with elements by ref.
- wait_for — wait for a selector or condition.
- screenshot — capture the page; the image is attached to the result.
- read_console / read_network — inspect logs and requests.
- evaluate — run a small script in the page.
How you use it
You don’t call it directly — you ask. Start your app, then tell the agent to check it. For example:
Run the dev server, open the login page, sign in with atest account, and confirm the dashboard renders with noconsole errors. Show me a screenshot.The agent navigates, drives the flow, checks the console, and drops the screenshot into the chat so you both see the result.
Localhost only, by design
127.0.0.1, ::1, and localhost. There’s no DNS resolution and no file://, and a guard blocks any mid-session redirect off loopback. It’s built to verify the app you’re working on, not to browse the internet.Screenshots you can see too
Every screenshot the agent takes is rendered inline in the chat, so visual verification is something you can eyeball alongside the agent — even when the agent’s model can’t see images, you can. Page content is always treated as untrusted data, never as instructions.
Part of the bigger picture