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.

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/.
• Open/Close DevTools, Inspect element here, Reload.
• Record — Local mode only, where the recorder exists.
• Copy the page address / Copy this element's selector (live, with an Inspect hit) / Clear the highlights.

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.

Next steps

→ Workspace · Integrations · Overview