Multi-session tests

Plenty of the most important flows involve more than one user. An admin sends an invite and a teammate accepts it. One account shares a document and another opens the link. A seller lists an item and a buyer purchases it. You can't test any of that with a single logged-in browser.

Each session is completely isolated

Open as many sessions as the flow needs. Every session gets its own:

• Server-side cookie jar — kept in memory per session and forwarded as the Cookie header, populated from Set-Cookie at every redirect hop.
• Namespaced localStorage — prefixed with __ts_{sessionId}_ so two sessions in the same tab never read each other's keys.
• Namespaced in-page cookies — prefixed with __tsc{sessionId}_.

That isolation is the whole point: Session A can be signed in as an admin while Session B is anonymous, and switching between them doesn't bleed auth state across the divide.

Why it isn't just two tabs

Same-origin sibling iframes in one tab share a single sessionStorage, so a naive two-tab setup would let whichever session wrote last clobber the other on the next reload. Test Chain recovers each frame's session id from window.name — scoped per-frame and surviving reloads — so parallel sessions stay honest even after a full page refresh.

Record the admin's half of the flow in one session, switch to the second, record the invitee accepting, and replay the whole thing as one suite.