Playwright storage state: what a persistent profile keeps

An agent that signs in on Monday should still be signed in on Tuesday. The standard Playwright answer is to save the storage state after login and load it into the next context, and for a test suite that is exactly right. An agent keeps accounts for weeks, though, and a site judges more than the cookie it gets back. We read Playwright's documentation on 29 September 2026 and set its storage state against a profile that keeps its whole directory.

What does Playwright storage state save?

Playwright storage state is a JSON snapshot of a browser context that a later context can load to start signed in. The storageState reference describes it as "current cookies, local storage snapshot, IndexedDB snapshot, origin private file system snapshot and virtual WebAuthn credentials", and three of those parts only when asked for.

The passkeys row needs one qualification. The credentials Playwright saves belong to its Credentials class, "a virtual WebAuthn authenticator" that replaces the native WebAuthn behaviour in the page. That is a test authenticator, not the machine's own, and the authentication guide adds a second caution: "The browser state file may contain sensitive cookies and headers that could be used to impersonate you or your test account."

Which 4 things does a restored state lose?

A restored state loses 4 things a persistent profile keeps: service workers with their caches, site settings with history, saved logins, and the device the session belonged to. An agent in a profile that stays signed in acts with every one of those sessions, and where its limits belong is covered in AI agent security.

The last row matters most for an agent. A site that set a cookie on a Windows machine with a particular screen and graphics card sees that cookie come back from whatever browser loaded the file. Playwright has its own answer for the rest of the list, launchPersistentContext, which keeps a user data directory on disk. Two limits come with it in its own documentation: "browsers do not allow launching multiple instances with the same User Data Directory", and pointing it at Chrome's main profile "may result in pages not loading or the browser exiting". A WhatsApp Web link is kept the same way: a linked WhatsApp Web session rests on the profile keeping the browser's storage between runs.

How does a session move between machines?

A session moves between machines as an encrypted copy of the identity, not as a copy of the browser directory, because the directory is both large and bound to the machine it was written on. On Windows Chrome's cookie key is wrapped with the operating system's data protection, and Microsoft's CryptProtectData reference says such data "usually can only be" decrypted "on the computer where the data was encrypted". A copied cookie file therefore arrives on the second machine as bytes nobody can read.

Scalebrowser therefore syncs what makes the profile that profile: its fingerprint values, its session, its stored logins and its passkeys, encrypted on the machine with a key the server never holds. The screen and graphics card are the exception: they are read from the machine the profile starts on, because a page can check them against that machine's own drawing. A profile is pushed at every stop, a timer every 15 minutes catches what a stop missed, and only one machine may hold it at a time; a start elsewhere is refused and names the machine it runs on. One limit stays and is worth knowing before you rely on it: a login that rests only on a local storage token does not survive the move, because only cookies can be both harvested and written back as of September 2026. The whole wall is part of keeping an agent signed in, and the profile sync page lists what travels and what deliberately does not. A Facebook profile that watches groups travels the same way, which keeping a Facebook session signed in describes. Signing in with a link mailed to an inbox is covered in Magic link login for an AI agent.

Do passkeys survive a crash?

Yes, when the passkey is written to disk the moment it is created instead of being collected at an orderly stop. A closed window or a crash ends a browser without an orderly stop, and our passkey acceptance bench, which kills the engine and then checks that the passkey is still stored, passed 8 of 8 checks in August 2026. What a site reads from the authenticator itself is covered in passkeys in browser automation.

Scalebrowser gives each agent its own isolated browser with a persistent identity, on your own machine, so a run stays signed in, handles the captcha and finishes without anyone watching it.

See how Scalebrowser does it

So which should you pick?

Storage state fits a test suite and a local storage login that has to change machines; a persistent profile fits an identity an agent keeps for weeks.

Our verdict: storage state is a snapshot of a login, and a persistent profile is the device the login happened on. For an agent that returns to the same accounts every day, the device is the part a site remembers.