Profile Sharing and Concurrency

Safely share browser profiles across parallel workers and browser pools

A browser loads profile data as a snapshot. Saving replaces the profile’s complete stored browser state; Kernel doesn’t merge cookies, storage, tabs, or preferences from multiple sessions.

Prefer tabs for one browser identity

For a personal assistant or another workflow where concurrent tasks act as the same end user, start one browser with that user’s profile and open multiple tabs in it. Tabs in the same browser context share a live cookie jar and persistent origin storage, so a login or cookie update in one tab is available to the others without loading the profile again or restarting Chrome. Tab-local state such as sessionStorage remains separate.

Open additional tabs with Playwright’s context.newPage(). Keep each task on its own Page, and coordinate actions that change shared account or browser state. See Playwright Execution for ways to run code against the browser.

Headful, non-GPU browsers use 8GiB by default. For tab-heavy workloads, set memory to 16GiB when you create the browser.

Use separate browser sessions when tasks need isolation, different proxies or browser settings, or independent failure and lifecycle boundaries. Each browser loads its own profile snapshot, so changes don’t propagate between those sessions while they run.

Use one writer and many readers

Multiple browsers can safely load the same profile when they don’t save changes. If a workflow needs to persist state, designate one browser as the writer and set save_changes: true only on that browser.

If multiple browsers write to the same profile, the browser that ends last overwrites changes saved by the others. Use a separate profile per independent writer when each browser needs durable state.

Topology	Recommendation
Concurrent tasks act as the same end user	Use one browser with one tab per task
Many browsers need the same starting state	Load one profile without save_changes
One browser updates state for future runs	Give that browser save_changes: true
Many browsers each need durable state	Give each writer its own profile
Several browsers must contribute selected state	Transfer the required cookies or storage explicitly

Detect active writers

Before starting a writer, list active browsers matching the profile ID and check profile_save_changes.

TypeScript

const profileId = browser.profile!.id;
const activeWriters = [];

for await (const activeBrowser of kernel.browsers.list({
  status: 'active',
  query: profileId,
})) {
  if (
    activeBrowser.profile?.id === profileId &&
    activeBrowser.profile_save_changes
  ) {
    activeWriters.push(activeBrowser);
  }
}

if (activeWriters.length > 0) {
  throw new Error(
    `Profile already has an active writer: ${activeWriters[0].session_id}`,
  );
}

The writer check and browser creation are separate requests. If several workers can start sessions concurrently, protect both operations with your own lock or lease so two workers can’t pass the check at the same time.

Understand running-browser behavior

Saving a profile doesn’t update browsers that are already running with it. Those browsers keep the snapshot they loaded at startup.

If the work can share one browser identity, keep it in that browser and use multiple tabs so every task sees live state. To apply a profile that was saved by another browser, start a new browser with the updated profile. You can also load the profile into a running browser that started without one, but loading restarts Chromium and disconnects CDP clients. See Load a profile after browser creation.

Use profiles with browser pools

A profile configured directly on a browser pool is read-only. Every browser in the pool shares that baseline, so save_changes on the pool profile is ignored.

For per-user durable state:

1. Create the pool without a profile.
2. Acquire a browser.
3. Attach the user’s profile with save_changes: true.
4. Release the browser with reuse: false so that user’s state can’t reach the next acquirer.

See Per-user profiles with browser pools for complete examples.

When a pool has a profile, refresh_on_profile_update replaces idle browsers after that profile is saved. Acquired browsers keep their existing state until they are released. See Refresh on profile update.