Most browser test tools ask you to install something first — a script tag, an npm package, a "testing mode" flag in your app config. That means the thing you're testing is never quite the thing your users see. It's your app plus a harness.
We wanted to record and replay flows against the actual production build, with nothing added to it. The only place that's possible is the network layer.
Test Chain sits between the browser and your app as a plain HTTP proxy. A request comes in for /proxy?url=https://yourapp.com/login, we fetch that page server-side, rewrite the links so they keep flowing back through the proxy, inject a small recorder script into the HTML, and hand it to the iframe. Your app never knows it's being proxied.
This sounds simple until you hit the edge cases that killed our earlier attempts:
fetch with redirect: 'follow' silently discards Set-Cookie headers from intermediate 302s. Email verification links that set an auth cookie mid-redirect would leave the session looking logged out. We had to follow redirects manually, hop by hop, to catch every Set-Cookie.x-refresh header for silent token renewal, and every request 401'd. We flipped it: forward everything except a small blocklist of proxy-internal headers.X-Frame-Options or CSP frame-ancestors specifically to prevent this. The proxy strips those on the way through, because the whole point is that we're standing in for the browser's normal navigation, not attacking the app.The honest downside: a proxy is more fragile than an SDK when a page does something genuinely unusual — service workers with hardcoded origins, WebAuthn, certain CSP nonces. We handle the common cases and keep expanding the list, but there's a ceiling.
What we get in exchange is that the flow you record is the flow your users actually take. No if (window.__TEST_MODE__) branches, no separate staging harness, no drift between what's tested and what ships.