Reuse Browser profiles

Browser profiles preserve supported cookies and local storage across fresh Browsers. They are project-scoped state, separate from the Job scenario and its working variables. HTML, Console and Desktop Linux do not use Browser profiles.

Configure a profile

1. Open the applicable enterprise/project/Job/Task settings.
2. In General, review Persist profile and Profile name on the same row.
3. Enable persistence when that Browser should save updated state.
4. Keep the inherited name, use Default when appropriate, or enter a meaningful explicit name.
5. Save, then open a fresh Toolbox or launch a fresh Session to test restoration.

When persistence is enabled with no explicit/inherited name, Browser uses the project profile Default. Merely displaying the prefilled name does not save it as a local override. Clearing a local name returns to inheritance after save; it does not erase existing stored profile contents.

Load and save are different

An explicit named profile can load existing state while persistence is disabled, allowing use without writing changes back. Without a name and with persistence disabled, the Browser starts clean.

Missing named state starts clean. A valid enabled save can create it. Unrestorable state produces an error rather than replacing the saved profile with an empty one.

Supported state is restored before Start URL and actions. Enabled persistence saves during supported controlled completion/closure. Abrupt loss can preserve only the last valid saved state, not the latest interaction you saw on screen.

Concurrent use

Two Browsers can load the same name independently. Their live state is not shared or merged; the last valid save replaces the stored state. Use separate names for independent accounts or coordinate work that must preserve a single sequence of changes.

Practical limits

Profiles are not a complete browser backup. Cookies and supported main-origin local storage are covered; IndexedDB, session storage, extensions, installed applications and complete browser directories are not.

A restored cookie does not guarantee that the external site will accept a session or skip verification. Keep account sign-in tests authorized and review real site feedback. External Subsessions can explicitly copy supported Browser state independently of variable inheritance; see Subsessions.