Playwright 1.61 and 1.62: what changed for AI testing

Most Playwright release notes are easy to skim past. A browser version bump, a few locator methods, a deprecation you'll deal with in six months. The 1.61 and 1.62 releases are worth more than a skim, because a lot of what landed maps directly onto the reasons AI-authored tests fail: state that wasn't set up properly, waits nobody declared, and failures with no evidence attached.

You can read the full notes on playwright.dev. Here's the subset that changes how you'd run an agent against a browser, and what each one actually saves you.

Virtual WebAuthn credentials

Passkeys have quietly become a testing problem. If your login flow supports WebAuthn, you either stub it out at the network layer, keep a separate password-based test account that doesn't match how real users sign in, or skip the flow entirely. None of those test the thing you shipped.

Virtual authenticator support means Playwright can register and assert a credential inside the test run. Your agent gets through the front door the same way a user does, and the auth path stops being the one journey nobody covers. For teams who moved to passkeys in the last two years, this is the single most useful item in either release.

WebStorage APIs and the state problem

Direct read and write access to localStorage and sessionStorage sounds minor until you think about what test setup usually looks like. Getting an app into a specific state often means clicking through four screens to produce a value that lives in a single storage key. Every one of those clicks is a chance to flake.

Setting the key directly and loading the page in the state you want cuts the setup path down to one step. That matters a lot for agent-authored tests specifically. An agent asked to test a checkout edge case will happily reconstruct the whole funnel to get there, and every step it adds is another selector that can drift. Give it a way to jump to the state and the resulting test is shorter and steadier.

Network diagnostics and WebSocket coverage in traces

Traces were already the best debugging story in browser automation. 1.61 extends them with better network diagnostics and WebSocket coverage in both traces and HAR files, which closes a gap that had been getting more annoying every year as more of the app moved to persistent connections.

If your app streams anything, live updates, chat, a progress feed, a failure used to leave you guessing about whether the socket was the problem. Now the frames are in the trace with everything else. This is the kind of change that pays off exactly once per incident, and then pays for the whole upgrade.

Isolated retries

Retries have always had a credibility problem. A test that passes on attempt two might be flaky, or it might have been poisoned by state the first attempt left behind. You can't tell which from the result, so a green retry is worth less than a green first run.

Isolated retries run the retry in a clean context rather than reusing whatever the failed attempt left lying around. That makes the second result mean something. A test that passes an isolated retry failed for a timing or environment reason. A test that fails one has a real bug or a real dependency problem underneath it. That distinction is the whole ballgame when you're trying to work out why a suite keeps flaking and whether the flake is in the test or in the app.

Bundled MCP and CLI

Playwright MCP and playwright-cli now ship with the package instead of living as separate installs. Practically, that means one fewer version to pin and one fewer thing to drift out of sync with your Playwright version.

The strategic read is more interesting. Bundling the MCP server is Playwright saying that agents driving the browser is a normal use case, not an experiment on the side. The interface an agent uses to click things is now maintained on the same release train as the interface your tests use. We covered the broader shape of this in how MCP and CLI tools fit into test automation, and this release is that argument getting official.

The rest, briefly

Should you upgrade?

Yes, and the decision isn't close if you're on anything older than 1.60. Playwright upgrades are usually cheap, the breaking changes are well documented, and you're trading an afternoon for better failure evidence on every run after that.

The one thing to plan for: if you run component tests, read the 1.62 notes properly before you bump. A new component testing model means your existing setup may need adjusting, and that's the piece most likely to eat a day rather than an hour.

What a new release doesn't fix

Better primitives make individual tests more reliable. They don't tell you whether the tests you have cover the journeys that matter, or which of the 900 specs in your repo are still earning their runtime. Playwright is a very good execution engine. Deciding what to execute is a separate problem, and it's the one that gets harder as the suite grows, not easier.

That's worth saying plainly because upgrade cycles have a way of feeling like progress on coverage when they're really progress on infrastructure. Both are good. They're not the same.

qtrl runs on real browsers and keeps a record of what each agent run checked and why, so the evidence problem these releases chip away at is handled at the platform level rather than per-test. When a run fails, you get the trace and the reasoning behind the steps that led there.

The coverage question gets answered the same way: structured test management underneath the automation, so you can see which journeys are covered, which are stale, and which never had a test at all. See how it works.