Live Browser

Studio launches its own Chromium — a dedicated, persistent profile, headless — and screencasts it live into a pane over the Chrome DevTools Protocol (CDP). The agent's Playwright MCP attaches to that same browser instance via --cdp-endpoint, so every click, navigation, and assertion the agent drives is visible as it happens, not just reported after the fact.

Why one shared browser

Because the pane is the browser the agent controls:

• Nothing to duplicate — there's no separate OS window; the visible pane and the automation target are the same process.
• State survives — the profile persists on disk, so logins and cookies carry across agent turns, MCP restarts, and even Studio restarts.
• New tabs are followed — OAuth popups, target=_blank links, and any page Playwright opens over the CDP endpoint are detected automatically; the pane switches to the newest target, re-injects the recorder, and restarts the screencast there.
• One browser per workspace, shared by windows — a second Studio window on the same workspace attaches to the browser the first one started, and drives it, rather than starting another.

Addresses

Studio applies one rule to every address on its way into the browser: the URL bar, Reload, the agent's navigation on every engine, and your project's app URL. It completes an address only when it has one reading, and refuses anything else with a sentence saying why:

• localhost:3000, an IP address, devbox:3000, or a private-network name such as app.local or app.test gets http://, because dev servers rarely speak TLS. Any other dotted host, such as example.com, gets https://.
• 0.0.0.0 (where a dev server says it's listening) becomes 127.0.0.1.
• A Windows path such as C:\site\index.html becomes a file:/// URL.
• A bare : or :3000, a path with no site (/checkout), a single word, or an address with spaces is refused.

Staying up

• Automatic recovery. If the browser crashes, Studio restarts it, up to 3 times in 2 minutes, and agents stay connected through the restart. After that, the pane says Browser closed and offers Relaunch browser; your logins and cookies are kept.
• A fresh launch starts clean. A new browser opens on a blank tab instead of reopening the last session's tabs.
• Idle browsers close. A workspace's browser that's off screen, not being cast, not used by an agent and not shared with another window closes after 5 minutes (30 seconds when memory is short). The next pane or agent that needs it starts it again, still signed in.
• Low-memory warning. When this computer has less than 1 GB of memory free, a Memory low chip appears in the chat header; below 512 MB it reads Not enough memory, because the Live Browser may not start reliably. Hover it for advice, and click it to check again. It clears by itself once memory frees up.

Recording

While the live browser is open, Studio's recorder captures steps as you (or the agent) interact with the page, so a manual exploration session can seed a new test.

Element Intelligence

The moment a page opens — not on hover, not behind an Inspect toggle — Studio marks the elements it already has test coverage for, right on the page: a plain-English name and what your tests actually do with it, like "Place order · Clicked by 2 tests". It's the same locator index every test targets, resolved against this page's live DOM. Marks are ranked by how many tests depend on them, so a handful get a caption at once and hovering any other promotes it, rather than papering the page with forty labels.

Turning on Inspect adds a second layer for the one element under your cursor: a dashed hover outline, a solid pinned boundary on click, and the live element card — including any memories linked to that element's tests.

A resizable dock along the bottom of the pane holds three surfaces built on the same intelligence:

• Overlay — what the agent's own marks show right now: marked, hidden, and "not covered" elements, with a Clear overlay action.
• Masking — which fields are being redacted and why (see Secret masking).
• Gap rows — uncovered elements named in plain English, each with a Draft a test action that seeds the chat.

These memory marks are Studio's own furniture, not evidence: they stand down automatically while DevTools is open or the agent's own marks are live, and they never appear in a captured screenshot.

Right-click menu

Right-click the live browser canvas for a context menu scoped to what's actually possible — disabled rows explain themselves with a tooltip rather than disappearing:

• Screenshot the page — a full-fidelity PNG via CDP (not the streamed screencast), saved under the workspace's .testrelic/screenshots/, with secrets masked the way a step capture masks them.
• Open DevTools / Close DevTools (see DevTools), Inspect element here, Reload the page.
• Record my clicks as a test — in the Code view, where the recorder runs.
• Copy the page address / Copy this element's selector (live, with an Inspect hit) / Clear the highlights.

DevTools

Open DevTools opens Chrome DevTools on the page in the pane: its DOM and styles, its console (including messages from clicks you make in the live view) and its network requests. Dock the panel with Dock to bottom or Dock to right. Undock into a separate window closes the panel and opens DevTools in your default browser instead.

Secret masking

If a page's form holds a credential — a password field, most obviously — its value never reaches the agent's context, the chat transcript, or stored history. Studio replaces it with [hidden] before any MCP tool result carrying it (an accessibility snapshot, a console line, a network body) leaves the browser layer, and the activity row reads "Typed into the Password box — value kept private" instead of quoting what was typed. Detection doesn't depend on recognizing the secret itself — an ordinary-looking password is still hidden — and it applies to every attached tool, not just Studio's own recorder, so it isn't something you have to turn on. Page snapshots sent to Claude Code, Codex and Cursor are masked the same way, and a recorded locator that would carry a secret is left out, and the step falls back to the next one, the element's CSS path at worst.

Next steps

→ Workspace · Integrations · Overview