The QA agent doesn't reason about your UI in the abstract — it drives a real browser against the running env. You can give it a sandboxed browser you watch live in the panel, or pair it to your own browser.

What it does

With a QA browser attached, the agent gets browser tools — navigate, click, fill, press, wait, snapshot the accessibility tree, screenshot, read text, evaluate, go back, reload. It uses them to walk through a test plan against your env's live preview, then tells you what it found (often filing a bug, or fixing it and re-running).

There are two modes, chosen per env.

Mode 1 — Sandbox browser (default)

withvibe runs a real Chromium in a dedicated sidecar container next to the env. The agent drives it, and you watch it happen live in the QA Browser tab — the same screen the agent sees, streamed into the panel.

Start and stop it from the QA Browser tab; the panel shows its status.
The live view streams same-origin, authenticated by a short-lived token — nothing extra to expose.
It's isolated from your machine: a throwaway browser in a container, gone when you stop it.

It's a sandbox, not your browser

The sandbox browser has no access to your cookies, logins, or extensions. That's the point — it's a clean, disposable environment. If the agent needs your real session, use mode 2.

Mode 2 — Your own browser

Switch the env's QA browser mode to user browserand the agent drives a tab in your own Chrome through a small extension. Useful when the test needs your real logged-in session, a specific extension, or a browser state the sandbox can't reproduce.

Install the withvibe QA browser Chrome extension.
From the QA Browser panel, generate a pairing token (it's short-lived — a few minutes).
Paste the token into the extension popup to pair it to the env.
The agent's browser actions now run in your paired tab.

If the agent tries to act before you've paired, the first tool call returns a clear error telling you to pair the extension (or switch back to the sandbox mode).

Choosing a mode

Sandbox when you want a clean, isolated, watch-along browser — the right default for most QA runs.
Your own browser when the test depends on your real session or local browser state.