verify

Browser & computer use

Squeezy can inspect and operate web pages in isolated Chromium, or explicitly claim tabs in an existing Chrome or Edge browser when the task needs its signed-in state. Native computer control reads accessibility state and acts inside one approved window, with screenshots when visual inspection is needed. Both surfaces use scoped permissions and bounded tool results.

contents

Isolated Chromium by default

Isolated browser control ships inside the binary and needs no MCP server, Node, Playwright, or extension. The tools appear when Chrome, Chromium, Edge, or Brave is installed in a standard location, or extension control is explicitly enabled. One bundled skill discovers the tool family and loads individual schemas when needed.

Each run starts a separate, isolated browser process on a fresh empty profile, and that profile is deleted when the browser closes. Work that has to stay signed in can use a named profile instead: Squeezy creates it empty inside its own storage, one session may hold it at a time, and each name is approved separately. Your everyday profile is never opened, imported, or copied. When a display is available the window is visible, so you can watch the run; otherwise it runs hidden, and either choice can be forced.

[browser]
headless = false                  # always show the window; auto-detected when unset
executable = "/path/to/chromium"  # only when discovery misses your install

Connect to existing Chrome or Edge tabs

Install the bundled extension and its Rust native host with squeezy browser extension install --browser chrome, or choose edge. Load the printed extension directory through the browser's extensions page, enable [browser.extension] enabled = true in user settings, and choose Connect in the extension popup. Registration and a live connection are separate states; squeezy browser extension status reports both.

Connection permits discovery of tab titles and URLs. Control requires a fresh tab snapshot and an explicit claim owned by the current Squeezy Session and its approved origins. The popup lists claimed tabs and offers Stop. Release, disconnect, cancellation, or Session shutdown leaves user tabs and the browser open. Profile management and the isolated browser's global download policy do not apply to the attached browser.

What it can do in a page

The agent reads bounded accessibility state and searches by role/name, label, text, placeholder, test ID, or CSS. Current refs support clicks, typing, checkboxes, option selection, modifier keys, pointer actions, and element-state waits. Nested frames keep their own document identity and require approval for cross-origin access. Screenshots, dialogs, emulation, console, and network diagnostics provide additional evidence. A typed batch can run up to ten approved same-session steps; connection changes, origin approvals, and transfers keep separate calls.

Emulation is per tab: phone and tablet layouts, dark mode, reduced motion, forced colors, and simulated vision deficiencies such as blurred vision or color blindness. Responsive and accessibility work becomes something the agent checks in a real rendering instead of inferring from the code. Screenshots need a model that can read images; without one, that single tool is withheld and the rest of the family still works.

Three operations carry extra guardrails. JavaScript evaluation runs one expression that cannot have side effects, approved against both the exact origin and the exact expression, and the browser rejects anything that would change the page, navigate, open a dialog, or reach the network. Sending a workspace file into a page needs an approval naming that origin and those exact paths. Owned Chromium denies ordinary downloads by default. An approved capture is bounded to 20 MiB and reaches the workspace only through a separate edit-approved save. Attached Chrome/Edge supports approved HTTP(S) URLs or resolvable link refs; buttons, blob links, and coordinate download triggers are refused before input. The capture preserves the user page and global browser download settings.

The boundaries

Every path through this surface is gated. The first two limits below decide what you can point it at:

Isolated Chromium reaches public addresses through a local egress gate that refuses loopback, private, link-local, and metadata destinations after DNS resolution. An attached user browser does not acquire that proxy or become an isolated network environment.
Origins are explicit. Navigation, redirects, frames, and popups are checked against their scoped authority. Cross-origin frames need separate approval; claiming one tab does not grant the rest of the browser.
It follows your web permission. Deny web access and browser control is denied with it. In Auto, the reviewer may clear an exact browser or desktop effect when that effect grants Reviewer authority. Secret or raw-clipboard disclosure, external file sending, and irreversible external or out-of-repository actions omit that authority and come to you instead. Full proceeds on its separate consent axis without calling the reviewer.
Not in the read-only modes. Chat and Plan withhold browser and desktop control on the same footing as file edits.
Off is off. [browser] enabled = false hides the tools and stops control. Owned Chromium is closed; attached user tabs remain open. A project may restrict the capability but cannot enable the extension connection or select a launch executable on your behalf.

Computer use: one window, on your say-so

macOS and Windows support one exact approved window or display. For a window, the agent first reads bounded accessibility state with current refs and explicit diffs, then invokes supported actions, edits values, selects text, or waits for a condition. Semantic actions require the exact granted window to be focused. Applications with incomplete accessibility can use visual inspection; screenshot and pointer-coordinate tools require a vision model, while semantic and text operations do not. Linux native desktop control is deferred in both GNU and fully static releases; Linux retains browser automation and the coding CLI.

Application discovery and launch are explicit and do not grant a window. Clipboard read, clipboard write, and system-key combinations are independent grants. Formatted paste requires all three, a readable focused editable control, and a supported clipboard backup; the parent checks ownership before restoring its temporary clipboard. Release drops the target and its native refs. Native computer actions follow the destructive-action permission setting.

[browser]
enabled = false        # hide the browser tools entirely

[computer_use]
enabled = false        # hide desktop control entirely

Why it exists

The point is verification. A web change is 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 way it does with builds and tests: run it, read the evidence, fix what the evidence says. Screenshots and page state come back as ordinary bounded tool results, and their bytes count toward the same tool-output accounting as everything else.

the contents list reaches every page in the docs