Aug 2025
By default, every BrowserPilot run gets a fresh, isolated browser session. Cookies, local storage, open tabs, and cached data are brand new. The session is created just before the run and torn down immediately after. This keeps failures reproducible and prevents runs from interfering with each other.
Isolation is the right default. It means a run that fails will fail the same way every time, with the same input. It means 100 parallel runs do not collide or leak state into each other. It means you can reason about your automation without worrying about what other runs are doing.
But isolation is not always what you want. Some workflows genuinely need continuity: staying logged in, carrying a user preference from one run to the next, remembering a choice made yesterday. For those, BrowserPilot offers persistent profiles.
A persistent profile is a saved browser state: cookies, local storage, and other session data. You can attach a profile to a run, and the browser starts with that state. When the run finishes, the new state is saved back to the profile. Next run, you start with the updated state.
This is useful for workflows that span multiple runs: a multi-day checkout process, a user onboarding that happens over several sessions, a daily routine that needs to remember what happened yesterday. But profiles come at a cost: state is shared, and a failure in one run can contaminate the next.
The key is to treat profiles as an explicit choice per workflow, not a global default. If a workflow truly needs state continuity, use a profile. If it does not, use isolation. Document why a profile is needed, and monitor the profile for state corruption. A well-designed workflow using profiles is elegant. A workflow that defaulted to profiles and now has mysterious interdependencies is a maintenance nightmare.