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

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 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 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 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 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.

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.

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. Once both are in place, your agent is in the loop at every stage of the development cycle.