Why can't one Cypress test drive two browsers at once for a two-user flow?

## The ceiling, stated exactly Cypress does not support controlling more than **one open browser at a time**. This sits in the Cypress documentation under *permanent* trade-offs, alongside the fact that a test is bound to a single superdomain — it is a property of the design, not a missing feature. A spec is launched into one browser, and every `cy` command in that spec addresses that browser. There is no second `cy` namespace, no browser handle, and no configuration key that starts a second instance for the same spec. That matters most for **collaboration flows**: a bank statement app where a back-office operator releases a statement and the customer's open session is supposed to show it, or a shared-account view where one holder's action must appear to another. ## A second tab is not a second browser Candidates often reach for the `@cypress/puppeteer` plugin here and overstate what it does. The plugin connects a Node-side handler to the **browser Cypress already launched**, so it can find and drive another page in that same browser. That is a second tab, not a second browser, and it does not give you two independent, isolated sessions — the tabs share the browser's cookie jar and storage unless you have gone out of your way to separate them. So the honest position is: - **Two browsers in one spec:** not possible, by design. - **Two tabs in one browser:** possible through the plugin, on Chromium-family browsers, with the automation code living in Node. - **Two genuinely isolated user sessions in one spec:** not what either mechanism gives you. ## Covering a two-party flow from one browser The productive move is to stop trying to *render* the second participant and start **driving** them from outside the browser. Cypress gives you two doors out of the browser for exactly this: 1. **`cy.request()`** issues an HTTP request from Cypress's Node process, outside the browser's page context. The operator's release action becomes a call against your API, made as the operator, in the middle of the customer's browser test. 2. **`cy.task()`** runs a function you registered in `setupNodeEvents`, which is the door for anything that is not a plain HTTP call — a database write, a message on a queue, a helper process you control. A spec then reads: visit the statements page as the customer, `cy.request()` the operator's release endpoint, and assert that the customer's page shows the released statement. One browser, two participants, no tab juggling. The same shape covers real-time features. Cypress does not intercept WebSocket frames, so the way to make "the other side" say something is to have your server say it — drive a helper process or an API endpoint from the spec and let the real socket deliver the message into the browser you are watching. ## What you can and cannot prove this way | you want to prove | one-browser approach | honest verdict | |---|---|---| | the customer's page reacts to another party's action | drive that party with `cy.request()` or `cy.task()` | fully covered | | the released statement is visible to the right account | assert in the customer's browser after the request | fully covered | | two people's browsers stay in sync in real time | server-driven message plus an assertion in one browser | covered for the receiving side only | | two independent browser sessions cannot see each other's data | not reachable in one spec | needs a different layer of testing | The last row is the one to say out loud in an interview. Some multi-session guarantees are genuinely outside a single-browser runner, and the mature answer is to place them somewhere else rather than to fake them. ## Why this ceiling is usually fine Two things make it far less painful than it sounds: - Most "two-user" scenarios are really **one user reacting to a state change**. The second user is a state producer, and producing state through the API is faster and far more deterministic than driving a second UI. - A spec that drives the second participant through the API fails for one reason at a time. A spec that drives two live browsers fails for the union of both browsers' flakiness, and you get to debug which half broke. The trap is the workaround that does not exist: there is no Cypress command that launches, attaches to, or switches between browsers, and claiming one is a fast way to lose an interview.