Browser & computer use
Squeezy can check its own work the way you would: open the page a change affects in a real browser, click through the flow, read the console, and look at a screenshot. On desktops, where you approve a specific window, it can operate a native application too. Both are built into the binary, both run behind your permission policy, and neither ever touches your everyday browser or its logins.
contents
contents
Built in, and present when a browser is
Browser control is a first-party tool family, not an add-on: there is no MCP server to install, no Node or Playwright, no extension. The tools appear automatically when a Chromium-family browser, Chrome, Chromium, Edge, or Brave, is installed, and they stay out of the model's way until web work actually comes up, a single catalog entry stands in for the family and the individual tools load on demand, so an unused browser costs your sessions nothing.
When it runs, Squeezy launches a separate browser process of its own. The default profile is a throwaway: your cookies, extensions, tabs, and signed-in sessions are never reused, and the profile is deleted when the browser closes. Workflows that genuinely need persistent state can use named profiles, which are Squeezy-owned, isolated from each other, and each gated behind its own approval, a normal browser profile is never imported.
What it can do in a page
The agent can navigate, resize the viewport, click, type, and select against a bounded accessibility snapshot of the page, handle dialogs, capture screenshots, and read bounded console and network activity, network results deliberately omit headers, cookies, and response bodies. It can also emulate devices and accessibility conditions per tab: phone and tablet layouts, dark mode, reduced motion, forced colors, and common vision deficiencies, which turns responsive and accessibility checks into something the agent verifies in a real rendering rather than asserts from the code.
Two operations carry extra guardrails. JavaScript evaluation runs one side-effect-free expression at a time, approved against the exact origin and the exact expression, and the browser rejects expressions that could mutate the page, navigate, open dialogs, or reach the network. Downloads are denied at the browser level by default; one approved transfer of at most 20 MiB can be captured, comes back as bounded metadata plus a checksum rather than file bytes, and reaches your workspace only through a separate, explicit save call that itself passes the edit policy.
The boundaries
This surface is an adoption question, not a safety escape hatch, because every path through it is gated:
- Permission-gated end to end: browser sessions and origins ride the same web approval policy as webfetch, and a document navigation is confined to the origin you approved, redirects included.
- Egress is gated too: every request the controlled browser makes goes through a local gate that refuses loopback, private-range, link-local, and cloud-metadata addresses even after DNS resolution, so a malicious page cannot pivot the browser into your internal network.
- Unavailable in the read-only modes: Chat and Plan withhold browser and desktop control on the same footing as file edits.
- Off is off: set [browser] enabled = false and the tools are not offered. The setting reloads in-session, and disabling it also terminates the running browser worker.
- Only your user-tier settings may choose the browser executable; a checked-in repository cannot point Squeezy at a binary to launch.
Computer use: one window, on your say-so
On macOS, Windows, and desktop Linux, Squeezy can operate a native application, when the active model can see images, and only after you grant it one exact window or display. Capture and input stay scoped to that grant for the session: before every click or keystroke, Squeezy re-resolves the focused window and refuses to act if it is not the one you approved. (Fully static Linux builds keep browser control but omit native desktop capture, whose backends need the host's desktop libraries.)
Clipboard read, clipboard write, and multi-key system chords are each separate grants, off unless you ask for them and approve them, and one release call drops the target and every grant with it. Because a desktop window can reach far beyond the repository, computer use rides the destructive approval policy, the strictest one, rather than the web policy.
[browser]
enabled = false # hide the browser tools entirely
[computer_use]
enabled = false # hide desktop control entirelyWhy it exists
The point is verification. A frontend change is only done when the page renders, the flow clicks through, and the console is quiet, and an agent that can check those things itself closes the loop the same way it does with builds and tests: run it, read the evidence, fix what the evidence says. Screenshots and page state flow back as ordinary bounded tool results, counted against the same output budgets as everything else.