---
title: "How to Connect an AI Agent to a Live Cypress Test Session"
url: "https://www.cypress.io/blog/connect-an-ai-agent-to-a-live-cypress-test-session"
description: "If you've used Cypress Cloud MCP, you know what it looks like when your agent triages a CI failure on its own: no copy-pasting, no context switching. But what…"
---

# How to Connect an AI Agent to a Live Cypress Test Session

May 22, 2026

By Emily Wisniewski

If you've used [Cypress Cloud MCP](https://docs.cypress.io/cloud/integrations/cloud-mcp?utm_source=blog&utm_medium=cypress.io&utm_campaign=ai_storytelling&utm_content=connect_chrome_devtools_to_app_blog), you know what it looks like when your agent triages a CI failure on its own: no copy-pasting, no context switching.

But what about when you're developing locally? When a test fails in `cypress open`, your agent is still on the outside. It can't see the runner, the DOM, or what the app looked like when it broke. You're still the one relaying that information.

Connecting the [Chrome DevTools MCP](https://github.com/ChromeDevTools/chrome-devtools-mcp/?ref=cypress-io.ghost.io) to your Cypress session changes that. Your agent gets direct access to the runner, the DOM, and your app's state at the moment of failure, so it can work from actual evidence rather than your description of the problem.

## Seeing It in Action

Here's what happens in the video above:

1.  **Cypress started in open mode with Chrome** — one test failed because a to-do item was not successfully deleted from the list
2.  **The agent queried the live browser** — returned _"6 passed, 1 failed"_ and the error of the failed test
3.  **The agent reviewed the git diff** —  the branch history revealed the test needed to be updated, not the app
4.  **The agent applied the fix** — Cypress detected the file change and hot-reloaded the spec automatically
5.  **Test went green** — resolved with no manual intervention

## What the Agent Can Work With

With [Chrome DevTools MCP](https://github.com/ChromeDevTools/chrome-devtools-mcp/?ref=cypress-io.ghost.io) connected to your Cypress session, the agent has live access to:

-   **Test pass/fail state and error messages** — queried directly from the live runner, not relayed by you
-   **DOM state at the point of failure** — what the app actually looked like, not a description of it
-   **Console logs and network request data** — useful for diagnosing failures that aren't purely about selectors or assertions
-   **Cypress command logs** — the full sequence of what ran before the failure

Alongside that, you can point your agent at the assets it already has access to, like failure screenshots, your local code, and your git history. Together, that gives it everything it needs to determine whether the test or the app needs to change.

## How to Set It Up: Two Simple Steps

It is simply matching the Chrome remote debugging port between both sides. Once they share a port, the [Chrome DevTools MCP](https://github.com/ChromeDevTools/chrome-devtools-mcp/?ref=cypress-io.ghost.io) can read the Cypress-controlled browser's live state.

**Step 1: Configure the Chrome DevTools MCP**

In your MCP config, set the Chrome remote debugging port (e.g., 59210). This tells the MCP to connect to an existing Chrome instance on that port instead of launching a new one.

_Without this, it spins up a fresh Chrome that has no awareness of your Cypress session._

**Step 2: Set the matching port when starting `cypress open`**

Set the `CYPRESS_REMOTE_DEBUGGING_PORT` to the same port, and the Chrome DevTools MCP can read the launched Cypress browser.

```bash
CYPRESS_REMOTE_DEBUGGING_PORT=59210 cypress open --e2e --browser=chrome
```

`CYPRESS_REMOTE_DEBUGGING_PORT` has been supported for many versions. If you are not on the latest Cypress version, you can still set up this connection!

## How It Fits with Cypress Cloud MCP

These two tools close different loops in your workflow. Together they cover the full development cycle from local iteration before you push to post-CI triage after a run goes red.

|  | Chrome DevTools MCP + Cypress | Cypress Cloud MCP |
| --- | --- | --- |
| When | During local development, or fixing a CI failure locally | After a CI run |
| What the agent sees | Live browser state, real-time test results, screenshots, logs | Historical run data, failure logs, Test Replay, flake trends |
| The loop it closes | Write → run → fix → hot reload | Push → CI red → triage → fix |
| Intended for | Fast local iteration before committing | Investigating failures at scale, cross-run patterns |

## Try It Out

1.  Set **`CYPRESS_REMOTE_DEBUGGING_PORT`** to a port of your choice (e.g., 59210)
2.  Run **Cypress** in open mode with a Chrome browser (`cypress open`)
3.  Configure **Chrome DevTools MCP** so it connects to that same port
4.  **Prompt** your agent to tell you about your latest spec run

If you're not yet using Cypress Cloud MCP for your CI failures, [that's worth setting up too](https://docs.cypress.io/cloud/integrations/cloud-mcp?utm_source=blog&utm_medium=cypress.io&utm_campaign=ai_storytelling&utm_content=connect_chrome_devtools_to_app_blog). Once both are in place, your agent is in the loop at every stage of the development cycle.