guides

Record what a login flow changes

Turn on the session recorder, run a login, logout or checkout, and see exactly which cookies the flow added, changed and removed — including the ones it set and cleared again on the way.

Why record instead of compare

The usual way to work out what a login did to your cookies is archaeology: look at the jar, run the flow, look again, and try to remember which rows are new. It misses things. It misses a session cookie that was only refreshed rather than replaced. It misses a flag that flipped while the value stayed the same. And it is completely blind to a cookie the flow created and cleared again before you looked.

The session recorder watches the cookie jar while the flow runs. It captures the site’s cookie changes in the order the browser reports them and folds them into a single answer: what did this flow do?

Record a flow

Open the site you’re debugging in a normal tab and open SessionCourier’s side panel on it.
Click the session-recorder toggle in the panel header — the icon-only control labelled Session recorder. Its dot turns red and pulses, and the panel switches to Recording example.com.
Run your flow in the page: log in, log out, check out, whatever you’re investigating.
Watch the diff fill in live as the changes arrive. Recording runs in the extension’s background worker rather than in the panel, so it keeps capturing while you switch tabs, and the panel — which stays open across the whole flow — refreshes itself as each change lands. There’s nothing to reopen.
Click Stop recording when the flow is done. The heading changes to What changed on example.com and the list stops moving.
Done returns you to the cookie list and keeps the recording — clicking the header toggle brings it back, with a badge on the toggle if the recording found anything. Discard throws it away.

Starting a recording costs you nothing but the click: no permission prompt, no page reload. The recorder never writes a cookie, so it cannot disturb the flow it is watching.

A recording is pinned to the site you started it on and to that site’s cookie store, so a recording made in a normal window never picks up incognito changes, and vice versa. The rows you get are the same universe of cookies the panel’s “this site” view shows you — no surprise third-party rows.

The four buckets

Every cookie the recording touched lands in one of four sections:

Added — didn’t exist when recording started, exists now. The session cookie a login writes ends up here.
Changed — existed before and after, and something meaningful differs. The row shows Before and After.
Removed — existed when recording started, gone now. A logout usually fills this one.
Transient — set and removed again during the flow. See below.

A cookie the flow re-set to exactly the same value isn’t listed at all: net no-op, nothing to report.

Cookies are matched on identity — store, domain, path, name, partition. So a cookie that comes back with a different name or on a different domain is not a change; it shows up as one Removed row and one Added row, which is what actually happened.

”Changed” is more than the value

Five fields count as a meaningful change: the value, the expiry, and the Secure, HttpOnly and SameSite flags. Two consequences are worth spelling out:

A login that only extends a session shows up. If your app refreshes the session cookie’s expiry rather than issuing a new token, the value looks identical and a naive comparison reports nothing. Here it lands in Changed, because the expiry moved.
A flag flip is spelled out on its own line. When the value stays the same but a flag changes, the row shows the flip explicitly — Secure Off → On, HttpOnly On → Off, SameSite Lax → None — instead of showing you two identical values and leaving you to guess what moved.

Transient cookies: the ones a snapshot can’t see

This is the bucket you cannot get any other way. A cookie in Transient was created and deleted during your flow: absent at the start, absent at the end. Compare the jar before and after and there is simply nothing there — no row, no trace, no hint that anything happened. The recorder catches it because it watches the sequence of changes, not the two endpoints.

That’s usually where the answer is when a flow misbehaves. The short-lived CSRF or nonce cookie the login sets and then consumes, the state cookie cleared on the way back from a redirect, the bucket assignment written and rolled back — all of them are invisible to a before/after diff and all of them can be the reason a flow fails. Each transient row is labelled “Set and then removed again during the flow.”

The recording lives in memory only

Captured changes are held in the browser’s session storage: in memory, never written to disk, and cleared when the browser closes.

That’s deliberate. Every captured change carries the cookie’s value — which, for the cookies you actually care about here, is a live session token. Keeping the recording in memory means those values are never stored at rest, which is also why recording an incognito flow is safe by construction: there is nothing to persist.

The trade-off to know about: a recording does not survive a browser restart. Quit the browser mid-flow, or before you’ve read the result, and it’s gone. Recordings are meant to be read in the moment, during the flow you’re debugging.

The recorder only observes

There is no replay, no restore, no export and no history. The recorder tells you what a flow changed; putting anything back is a separate job. If you want to be able to return to the session you had, export it before you run the flow — see import and export cookies — or set individual values back by hand in the editor (create, edit and delete cookies).

Limits

Without host access, the diff can be empty or partial. The recorder captures whatever the browser’s cookie-change events deliver, and those only arrive for sites SessionCourier is permitted to observe. Recording deliberately doesn’t prompt for that grant — the toggle stays a zero-friction click — so on a site you haven’t granted access to, a recording can come back empty or with only part of the story. If the cookie list for the site is showing SessionCourier’s grant-access hint, treat a recording of it the same way. Details in the permissions reference.
Cross-site SSO is only partially captured. Capture is scoped to the site you started recording on. A flow that sends you off to a third-party identity provider and lands you back in the app records the app’s own cookies — not the provider’s, which live on the provider’s domain. You see the session your app ended up with, not everything the identity provider set along the way.
The reconstructed “before” is only as old as the recording. The recorder has no snapshot of the jar from before you started; it works out each cookie’s prior state from the first change it observes. If the first thing it sees for a cookie is a plain add — with no preceding removal to reveal what was there — it reports the cookie as Added, even if an older cookie of that name had existed and been cleared before recording started. Start the recorder before you run the flow, which is the intended use, and the report is exact.