WebdriverIO v10: What's New for Agent Verification Loops

What Is New in WebdriverIO v10?

WebdriverIO v10 adds a set of features built for agents and verification loops, plus a cleanup of the core that removes old protocol code. The table maps each headline feature to the job it does.

Three TestMu AI engineers are credited in the release: Navin Chandra for BiDi request headers, window switching in classic sessions and attachToSession fixes, Swastik Baranwal for element array and Electron fixes, and Sai Krishna for shutting down the Appium server cleanly when a run completes.

How Does wdio session Let an Agent Drive the App?

wdio session keeps one WebdriverIO session alive across many short shell commands. That matches how coding agents work: run a command, read the output, decide the next step. A full loop looks like this:

npx wdio session open chrome http://localhost:3000
npx wdio session snapshot --interactive
npx wdio session click e3
npx wdio session exec -e "await expect($('aria/Cart (1)')).toBeDisplayed()"
npx wdio session export --out test/specs/cart.e2e.ts
npx wdio session close

The snapshot gives every element on screen a short ref such as e3, so the agent acts on a handle instead of inventing a selector. The export step turns the commands that worked into a regular WebdriverIO spec that you can read and rerun without a model.

• Platforms - the same commands work with Chrome, Firefox, Edge and Safari, Android and iOS through Appium 3, Electron, Tauri and Dioxus, and native macOS and Windows apps.
• Setup checks - npx wdio session doctor android reports what is missing on the machine before the agent gets stuck.
• Agent skill - npm init wdio offers to install a wdio-session skill, so Claude Code, Cursor, Codex and Copilot know the commands.
• Origin - the command started as wdiox, a side project by Vince Graics, and moved into the core CLI for v10.

The project also published an open benchmark that gives coding agents real tasks on live websites and swaps only the browser tool, keeping the model, harness and prompt the same. According to the release post:

• It runs a 100-task sample of Online-Mind2Web, real tasks on live websites, judged by WebJudge with a model from another family.
• Reviewing every task wdio session failed exposed gaps with long pages, frames and custom widgets; fixing them took it from 22 to 31 of the first 50 tasks with Claude.
• With 100 tasks and one run each, the 95% confidence interval of a score is still about plus or minus 10 points, so the leading setups are effectively tied.

How Does browser.act() Turn Intent Into Replayable Code?

browser.act() comes from the new @wdio/ai-service. It asks your model to perform a step once, records the WebdriverIO commands it ran, and replays them from a cache file on later runs. For example:

import { browser, expect } from '@wdio/globals'
import { z } from 'zod'

it('adds a shirt to the cart', async () => {
    await browser.url('/shirts/blue')
    await browser.act('Add the blue T-shirt in size M to the cart')

    const cart = await browser.extract(
        'the line items in the cart',
        z.array(z.object({ name: z.string(), size: z.string(), qty: z.number() }))
    )
    expect(cart).toContainEqual({ name: 'Blue T-Shirt', size: 'M', qty: 1 })
})

• Record - on the first run, the instruction goes to your model with the wdio session actions. Each step runs as a regular WebdriverIO command and is written to __act__/cart.e2e.ts.json next to the spec.
• Replay - later runs replay those commands without a model, so a passing run spends no tokens on act() and runs as fast as hand-written code.
• Heal - when a recorded step fails, the service tries the other recorded selectors first, then the element's role and accessible name, still without a model. Only if that fails does the model continue from the failing step.
• Eject - npx wdio-ai eject test/specs/cart.e2e.ts converts the recorded act() calls into plain WebdriverIO code when you want the model gone for good.

The heal step is stricter than selector-only self-healing. Every recorded step stores its effect, meaning the requests it sent, the navigation it caused and the page parts it changed, and a heal only counts when it does the same thing. A heal onto a look-alike Add to cart button in a wishlist widget sends a different request, so the test fails instead of passing on the wrong element.

extract() is never cached: it reads the current page and calls the model on every run. You choose the model, whether Anthropic, OpenAI, OpenRouter, or a local model through Ollama, LM Studio or llama.cpp.

What Changes for Debugging and Multi-Tab Tests in v10?

The release post names Playwright's trace viewer and Cypress's time-travel debugging as the standard WebdriverIO users had been missing. WebdriverIO DevTools is the answer, in two parts:

• Live mode - a dashboard opens while tests run and shows every command, the page, and console and network logs, with one-click reruns of a single test.
• Trace mode - records a portable trace.zip that you can replay offline, attach to a CI run, or give to an agent to compare against a passing run.

Multi-tab tests change too. In a WebDriver BiDi session, tabs, windows and frames are WebdriverIO.BrowsingContext values you hold, so a test can check a payment iframe, a second tab and the main page without switching back and forth:

• browser.url() returns the page it opened.
• browser.newWindow() returns the new tab without switching to it.
• context.frame() returns a frame of that page, and commands on each value run in that context.
• switchWindow and switchFrame throw in BiDi sessions; classic sessions keep them.

What Breaks When You Upgrade From WebdriverIO v9 to v10?

The v10 migration guide says most breaking changes cannot be applied by a codemod, because they depend on what your tests mean. These are the ones most suites hit first:

The project ships a migration skill for coding agents. Install it from the project you are upgrading, then ask your agent to migrate the suite:

npx skills add webdriverio/webdriverio --skill wdio-v10-migration

Strict selector violations only show up when the suite runs, so plan a full run after the upgrade. If your suite relies on custom matchers, check the WebdriverIO assertions you use against the expect-webdriverio 8 changes.

How Do You Run WebdriverIO v10 on TestMu AI?

WebdriverIO connects to TestMu AI through the standard WebDriver hub, set up as shown in the WebdriverIO Selenium grid docs. Before you move a v10 suite there, check these points:

• The service plugin - wdio-lambdatest-service 4.0.2, the latest release on npm, declares peer support for WebdriverIO 7, 8 and 9. Until it lists v10, set the hub hostname and your credentials directly in the config.
• Appium 3 on real devices - TestMu AI offers Appium 3.0.2 on Android 13, 15 and 16 and iOS 16, 17, 18 and 26 devices, while the default version is still Appium 2. Set the appiumVersion capability to 3.0.2, as the supported Appium versions page explains. The WebdriverIO Appium guide covers the rest of a mobile setup.
• Agents through MCP - @wdio/mcp lists TestMu AI's real device and browser clouds among its cloud providers, so an agent can open a cloud session from the same MCP server it uses locally.
• Agent skills - TestMu AI's open-source agent skills include a webdriverio-skill that teaches Claude Code, Cursor and Copilot to write WebdriverIO tests for the grid.

Once the suite runs on v10, the cloud covers the platforms v10 targets:

• Automation Cloud - runs WebdriverIO, Selenium, Cypress and Playwright suites in parallel across 3,000+ real browser and OS combinations, with no grid to maintain.
• App test automation - runs Appium suites on 10,000+ real Android and iOS devices, which is where v10's cross-platform mobile commands such as tap, swipe and pinch need real hardware.
• WebdriverIO on HyperExecute - orchestrates WebdriverIO runs with Mocha or Jasmine from a single YAML file.

Getting Started With WebdriverIO v10

Upgrade Node.js to 22.19 or later, install the migration skill, and run the full suite once before you change anything else; the failures it prints are your migration list. New projects can run npm init wdio and accept coding agent support to get wdio session and its skill in one step.

When the suite passes locally, move it to WebdriverIO testing on TestMu AI and run it across the browsers and devices your users actually have.