Browser Profiles & Persistent Context

How Cloud Browser profiles and the Persist Browser Context toggle work together — and how that compares to local Chrome profiles.

The mental model

Cloud Browser uses two independent settings that combine to control how state is saved between sessions.

Cloud Profile = a storage-state identifier (which "address" to read/write).
Persist Browser Context = a kill-switch (whether to actually read/write at all).

Profile = the address. Persist = whether you actually use the address. They're orthogonal. Local Chrome profiles work differently — there, context is always on because you're driving your own real Chrome installation.

Cloud Browser Profile

A cloud profile (e.g. a profile you've named yourself, or the Default Cloud Profile) is just a storage-state identifier. Think of it as an S3 key:

On session start: if you pick a profile, the runtime downloads any saved cookies + localStorage + IndexedDB from that key.
On session close: the runtime uploads the current state back to the same key, ready for next time.

That means signing into Gmail using one of your profiles from any surface (Open Profile, Visual Studio, AI Browser Agent, SDK) puts the Gmail session at the same shared address. Pick the same profile later from any other surface and you're still signed in.

The Default Cloud Profile uses the bare user id as the storage key — pre-existing logged-in state from earlier versions remains linked to it.

Persist Browser Context (the kill-switch)

The Persist toggle decides whether the runtime does the load/save dance at all:

ON (default): runtime reads any saved state for the chosen profile on start, writes it back on close. State sticks across sessions.
OFF: runtime ignores any profile identifier — no download at start, no upload at close. Every session begins fresh.

OFF is non-destructive. Turning it off does not delete state already saved at the profile key — it just stops touching it. Toggle it back on and the previous state loads again on the next session.

Where the toggle applies: Visual Studio workflow runs on the cloud browser follow it. Opening a cloud profile with the Open icon in the profile selector always loads and saves that profile's state — that's how you sign in to sites ahead of time.

Common questions

"If I use a profile with Persist OFF, will my cookies be retained next time I use the same profile?"

No. Persist OFF means the runtime never touched the cloud store for that session — nothing was uploaded at close, so there's nothing new there. The profile's storage still holds whatever state was last saved with Persist ON (untouched, not deleted).

"If I had Persist ON before, then turn it OFF — will my previous logins still be used?"

No. Persist OFF gates both loading and saving. The runtime won't pull the prior state from cloud storage even though it's sitting there. Toggle Persist back ON later and the prior state would be loaded again (it never went away).

"Does the same profile work the same way across the AI Browser Agent, Visual Studio, Open Profile, the SDK, and the public API?"

Yes. Every cloud surface routes through the same contextKeyFor(userId, profileId) helper, so all paths read and write the same shared storage key for the same profile. State you create in one place is visible in every other.

"What happens when I pick the Default Cloud Profile with Persist ON?"

Same load/save dance, but at the bare-userId key (back-compat with workflows that pre-dated multi-profile support). Any pre-multi-profile cloud sessions you'd run are linked there.

How local Chrome profiles work (different model)

Local Chrome profiles are the ones managed by the Prompteryx Desktop, running against your own installed Chrome. They behave very differently from cloud profiles:

Context is always on. A local Chrome profile lives in a real Chrome user-data directory on your machine. Cookies, localStorage, extensions, autofill — every browser action persists automatically the way Chrome normally works. There's no separate "Persist" toggle and no upload/download — the state is just there on disk.
Switching profiles = switching Chrome user-data dirs. The desktop app spawns Chrome with the chosen profile's --user-data-dir, so each profile is fully isolated from the others (different cookies, different sign-ins, different extensions) — just like your everyday Chrome profile switcher.
Workflows survive a power-off. Logging into a service on a local profile means the session sticks on your machine until you clear cookies the normal way. No upload step is involved.

Practical upshot: pick local profiles when you want a personal, "I'm using my own Chrome" experience that survives between runs without any sync model to think about. Pick cloud profiles when you want shared state that any cloud surface (or the SDK, or the API) can read on demand from anywhere.

Quick rules of thumb

Want your cloud session to remember you next time? → pick a named cloud profile, leave Persist ON.
Want a one-off fresh cloud browser that leaves no trace? → flip Persist OFF (the profile pick is then ignored).
Using the SDK / public API and don't want to think about profiles at all? → just call px.cloudBrowser.sessions.create(). With no profileId the call defaults to ephemeral.
Driving your own machine? → pick a local Chrome profile. Context is always on by design.