AI Features in Cypress & Selenium

cy.prompt(steps, options) is a Cypress command that accepts an array of English strings, asks a model to interpret each step, evaluates the page DOM to pick selectors, generates ordinary Cypress commands and runs them. It exists since Cypress 15.4.0. It is for end-to-end tests only (not component tests) and runs in Chromium-based browsers (Chrome and Edge).

Source: cy.prompt() API reference

The command yields whatever the last generated Cypress command yielded, so cy.prompt([...]).closest('form') works when the last step is a click. A spec written against Bookshelf looks like this. It combines a search, a placeholder for the term and a placeholder for the expected text, so the step strings stay identical across iterations (see below). It is written from the documentation and was not run, because cy.prompt needs a Cypress Cloud account.

Source: Generate tests with cy.prompt

{{term}} and {{expected}} are replaced when the step executes. Because the strings never change, the second iteration reuses the code that the first one generated.

Cypress Studio records your clicks, typing and selections into a spec (click, type, check, uncheck, select), and a right-click adds manual assertions. Studio AI is the opt-in layer on top: as you record, it compares the DOM before and after each interaction and recommends an assertion with a one-line comment about what it validates. The assertion code is inserted immediately (collapsed), so you can save and run the test before deciding; each recommendation has Accept and Reject buttons, Accept all and Reject all, and hovering shows the before and after DOM snapshots with the asserted element highlighted. Recommended kinds are visibility, existence, text, length, form values and states, attributes (classes, ARIA) and URL and title. The model sees only the visible UI changes; it has no access to application code or business rules.

Requirements and limits at the check date: Cypress 15.11.0 or later, a Cloud account and linked project for the recommendations (the recording itself needs neither), sourcemaps enabled, a trial of six accepted recommendations per browser session without logging in, 60 recommendations per hour on a free account and 300 on a paid one. Studio supports E2E only and cannot record across origins, in iframes or in Shadow DOM; recommendations are disabled while the test is failing and can be affected by animations or very large pages. Studio AI is labelled Beta and is included at no extra charge during the beta. It was not run here (no Cloud account). The Studio basics are in Cypress: Debugging, Studio, Plugins & Reporters.

Three more AI capabilities live in Cypress Cloud rather than in the App, all enabled by default and none needing a paid plan except the last:

See Cypress Cloud for the product around them. These features were not exercised because no account was available.

Cloud MCP is a remote Model Context Protocol server hosted by Cypress at https://mcp.cypress.io/mcp. It does not drive a browser and cannot run or edit tests. It lets an agent read Cypress Cloud data: recorded runs, per-spec and per-test results, failures with stack traces and Test Replay links, flaky tests, failure screenshots, and Accessibility and UI Coverage reports. It reached general availability on 20 May 2026 and is included on every Cloud plan at no extra cost.

Source: Cloud MCP

The access model matters for the threat model. An organization admin enables the integration; each user then authenticates with OAuth (recommended: the client opens a browser sign-in and the session lasts 30 days) or a personal access token generated in the profile page (shown once, with a chosen expiry). The server is read-only and user-scoped: it cannot modify test code or delete runs, and an agent sees only what the signed-in user may see. It uses the standard MCP authorization (OAuth 2.0) over streamable HTTP, and is limited to 100 tool requests per hour per user on every plan. Disabling the integration on the organization’s Integrations page revokes every user’s access immediately. For Claude Code the documented commands are below (documented, not run: no Cloud account was available); the other clients in the documentation (Claude Desktop, Cursor, VS Code, Copilot CLI, Codex, Antigravity) use the same URL.

Source: Cloud MCP, Claude Code (CLI)

The documentation’s example prompts are good templates: "Check Cypress Cloud for the latest run on this branch. Give me a high-level summary of any failures." or "Find the failing tests for [Run URL]. For each failure, look at the stack trace and the failure screenshot, check my local code, and propose a fix." Two practical points from its troubleshooting section: say "Cypress Cloud" in the prompt so the agent chooses these tools, and point the agent at a run by branch, commit, run number or URL because a red CI job still has a recorded run. For terminal-only agents the Cloud CLI (cy-cloud, package @cypress/cloud, JSON output, Beta) is the scriptable counterpart and is covered in the Cypress Cloud page. How MCP servers, hosts and transports work in general is explained in MCP Architecture and Connecting MCP Hosts, and how to test them in MCP Testing & Debugging.

The Cypress AI Toolkit (https://github.com/cypress-io/ai-toolkit, MIT licence) publishes five skills, which are instruction files that a coding agent loads when the task matches. They are free, need no Cloud account and have no usage limits.

Source: Cypress AI Skills

Install them from the GitHub repository with the skills CLI or the GitHub CLI; the toolkit is also published as an agent plugin (a Claude plugin marketplace entry and a Cursor plugin are described in its README). There is no npm package to install the toolkit: do not look for one, and treat any package that claims to be a Cypress "AI toolkit" on a registry as unrelated.

Source: Install Cypress AI Skills

These commands were not run (they modify an agent configuration, and no coding agent was used for this page). A skill is a prompt that you can read before you install it; do that, as for any third-party instruction file that will steer an agent with shell access (see Prompt Injection).

cypress tap (Cypress 15.21.0 or later, Beta, free, no Cloud account) is a subcommand of the cypress CLI that attaches to a running cypress open session and exposes what the App shows: run a spec, read the reporter and Command Log, and inspect the application-under-test as it was at a given command. An agent that can run shell commands (Claude Code, Cursor, Copilot, Codex and others) can then verify its own test instead of reporting a bare pass or fail. It works only with open mode (not cypress run) and only with Chromium-based browsers, including Electron. If the CLI and the session are on incompatible versions it stops and says so.

All commands accept --session <pid> (-s) when several sessions run, --json (what scripts and agents should prefer) and --timeout <ms> (30,000 by default). Four rules from the documentation matter for any agent loop: only passed and failed are verdicts; a finished run stays readable until the next one starts, so record startedAt before re-running and wait for a verdict with a different startedAt; a spec that fails to build sits in loading forever, so the poller needs its own timeout; and passed does not prove tests ran (an empty spec passes with zero results). Do not touch the Cypress window while an agent drives it, because a pin is the same state the Command Log click changes.

The following transcript was recorded against Bookshelf (on its own port) with a cypress open --e2e --browser chrome session and Cypress 16.2.0. The spec has one correct test and one that uses a stale locator on purpose, the situation an agent has to repair. The commands were typed by hand in the order that the cypress-tap skill prescribes; no agent or skill was involved. The project path is shortened to <workspace>.

Source: cypress tap

The first call to run started a Chrome window by itself (the session had no browser). The agent then asks for the failing test and, with dom, aria and inspect, for what is really on the page:

Source: cypress tap, Debug a failing test

The page answers the question the agent actually had: the element exists, with the test id search-input, not search-box. After the locator was patched the same command sequence reported passed with ✓ 2 and a new startedAt. Compare this with the equivalent loop of the Playwright healer in Playwright Test Agents: both end in a failing test read from structured evidence, a patch, and a re-run, but Cypress exposes it through a CLI attached to the open App rather than through MCP tools. Cypress itself says cypress tap is the local counterpart to Cloud MCP and the Cloud CLI: tap gives the agent your machine while you are writing the test; the others give it recorded CI runs afterwards.

Selenium added a documentation page called Using AI coding agents with Selenium (the documentation tree has a top-level AI Agents entry; the page was added on 28 September 2026 and announced in a blog post of 29 September 2026). Its premise is an observation about training data: much of what models learned about Selenium describes Selenium 2 and 3, whose APIs were removed years ago, and the most repeated patterns (sleeping to wait, downloading driver binaries, XPath copied from DevTools) were never good practice. The page does not add a feature. It tells you what to give the agent and what to correct.

Give the agent the current documentation. In order: https://www.selenium.dev/llms.txt (a curated index following the llmstxt.org convention, which deliberately leaves out the legacy Selenium 2 and 3 pages and the Chrome DevTools Protocol pages), the documentation, the examples directory of the documentation repository (every code tab on the site links into code that is compiled and executed against current releases), the API documentation of each binding, and the changelogs. The llms.txt file also carries a short block of generation notes at the top: Selenium Manager resolves drivers, prefer explicit waits, BiDi is the supported route for events and network, desired capabilities were removed. The page recommends a negative instruction as well: if an API is not in the current documentation or API reference, it does not exist.

Write the project rules down. The page provides a block for AGENTS.md, CLAUDE.md or another rules file. This adapted excerpt keeps the structure and sets the baseline of this page (the official template names the version of the day, 4.49.0 at publication); replace the placeholders with your commands.

Source: Using AI coding agents with Selenium, Write the project rules down

The page then lists, for Java, Python, C#, Ruby, JavaScript and Kotlin, the removals models get wrong most often. Python’s list is representative: find_element_by_* helpers were removed in 4.3 (use find_element(By.ID, "...")); the executable_path and desired_capabilities keyword arguments were removed in 4.10 (pass service= and options=); options.headless = True was removed (use --headless=new); switch_to_alert() was removed (use switch_to.alert); and webdriver-manager must not be installed. The long-form explanations are the part worth reading before you review agent output: Selenium Manager (4.6 and later) finds the browser and the matching driver and, since 4.11, can download the browser; DesiredCapabilities predates the W3C standard and unprefixed non-standard capabilities can fail a session; sleeping is the main source of flakiness, and an agent that "fixes" an intermittent test by raising a timeout is hiding a race, not removing it; Grid 4 is started with standalone, hub and node subcommands rather than the Grid 3 -role flags. The same facts appear in this section’s sibling pages: Selenium: Drivers, Browsers & Options, Selenium Waits & Expected Conditions and Selenium IDE, Legacy Components & Upgrading to Selenium 4.

The page’s recommended first step for browser access "needs nothing new": tell the agent it may write a throwaway Selenium script, run it and print what it finds. The script navigates, dumps candidate elements, tries a locator and reports back, and because it uses the same stack the real test will use, it cannot disagree with the test about what Selenium sees. This is the same observe-then-write loop that an MCP browser tool provides, with the advantage that no extra dependency enters the project. The script below is what such a verification looks like for the Bookshelf catalogue; it was run (Python 3.13, Selenium 4.51.0, headless Chrome 155, against the application on its own port), printing the evidence an agent needs before writing the test.

Source: Using AI coding agents with Selenium, Let the agent drive a real browser

Its output, unedited:

Source: WebDriver BiDi Logging Features

The script was written and run by hand here; the page describes the pattern, and an agent following the rules file above would produce something similar. Note the explicit wait on the number of cards instead of a sleep, the data-testid locators and the BiDi handlers (the console and JavaScript-error handlers need enable_bidi, which asks the driver for the webSocketUrl capability). A script like this, which also checks for console and JavaScript errors, is a cheap guard against an agent declaring a flow "working" while the page logs an exception.

The Selenium project does not publish an MCP server. The guide says so in one sentence: there are community-maintained Model Context Protocol servers that expose Selenium as tools an agent can call (open a browser, click, type, take screenshots), they are third-party projects and are to be evaluated like any other dependency. That is a statement about trust, not about quality. Such a server executes browser commands on behalf of a model, so the questions to ask are those of Excessive Agency and Tool Security: who maintains it, what does it expose (arbitrary script evaluation? file access?), does it run in an isolated profile, and what happens when a page tries to steer the agent. If you want an MCP-driven browser with a project behind it, the maintained choices are Playwright MCP & CLI and Chrome DevTools for Agents; the throwaway script above often removes the need for any of them in a Selenium project.

For anything an agent needs beyond clicking (console messages, JavaScript errors, network observation or interception, script evaluation, screenshots of a browsing context), the Selenium documentation and llms.txt point at WebDriver BiDi, the W3C standard (Working Draft of 8 October 2026) created by the Selenium project together with the browser vendors. It is the cross-browser replacement for the Chrome DevTools Protocol, which the documentation now treats as a temporary measure, keeps out of llms.txt, and tells agents not to use as a basis for new code. This is what makes Selenium’s agent story coherent: the protocol that carries the agent’s debugging information is a standard that Chrome, Firefox and the other BiDi browsers implement themselves, not a vendor-specific channel. The detail of the API, with Python and Java examples, is in Selenium: WebDriver BiDi; the background of how it differs from classic WebDriver and CDP is in How Browser Automation Works.

The guide ends with a workflow that applies to any tool, and it is worth adopting almost verbatim:

Handing the agent the real exception rather than "the test failed" is the other lever: Selenium’s exceptions are specific (NoSuchElementException, StaleElementReferenceException, ElementClickInterceptedException, SessionNotCreatedException) and the documentation has a page for each; a screenshot taken at the moment of failure usually explains an intercepted click faster than the stack trace does.