Automated browser testing

Speedwave can drive a real browser from a session: open a page, click and type, fill in forms, take screenshots, read the rendered DOM, and check that elements or text are visible. This runs on a headless Chromium browser, provided through Microsoft’s official @playwright/mcp server. See Web automation for how this fits alongside Speedwave’s other integrations.

When to reach for it

A plain web fetch only handles static HTML. Reach for browser automation when a page is rendered by JavaScript, is a single-page app, needs time to load content, or when the task itself needs a screenshot, a rendered DOM snapshot, or interaction with the page.

Tip

Prefer a plain web fetch first for docs, READMEs, blog posts, and other server-rendered pages. A browser session is far more expensive than a fetch call, so drop to it only once a fetch does not work.

What Speedwave can do in the browser

The tools cover navigation, extraction, interaction, and assertions:

• Navigation: moving between pages, going back, switching tabs.
• Extraction: accessibility snapshots, screenshots, reading console messages and network requests.
• Interaction: clicking, typing, filling forms, selecting options, pressing keys, hovering, dragging.
• Assertions and locators: checking that an element or text is visible, and generating locators for it.

Screenshots and page dumps come back inline in the tool response. The browser does not write files into your project. See Data and privacy for what a session sends to the model.

Testing against your own app

The browser runs inside a container, so localhost there means the container, not your machine. To point Speedwave at a dev server running on your computer, use host.docker.internal instead of localhost in the URL, for example http://host.docker.internal:4200 for a dev server on port 4200.

Sessions do not persist

Each session starts from a clean browser profile. Cookies and any storage from one session do not carry over to the next, so a login performed in one run is not available in the next one.

The browser container gets the same hardening as every other worker: every Linux capability dropped, no privilege escalation, a read-only root filesystem, and no execution from temporary storage. Its network reach and what it can and cannot connect to on your machine are covered in Isolation model.