Skip to main content

Concurrency & Isolation

Understand how browsers and sessions let agents run parallel work without state leaks.

Written by Maggie

Browser-act separates identity from work:

  • A browser is an identity: cookies, profile, fingerprint, proxy, and description.

  • A session is a workspace: one task's current page, tabs, state, and command flow.

This model lets agents run multiple tasks without mixing state.

Concurrency models

flowchart TD
  Task["Agent work"] --> Cross["Separate browsers"]
  Task --> Shared["Shared browser"]
  Task --> Private["Private sessions"]

Model

Isolation level

Shared state

Best for

Cross-browser parallelism

Browser identity

Nothing by default

Multiple accounts, regions, or identities

Multiple sessions on one browser

Session workspace

Cookies and login state

Parallel tasks on the same account

Stealth privacy sessions

Fresh profile per session

Nothing persistent

One-off public data collection

Cross-browser parallelism

Each browser has independent cookies, fingerprints, and proxy settings.

browser-act --session account-a browser open <browser_a_id> https://example.com
browser-act --session account-b browser open <browser_b_id> https://example.com

Session names must be globally unique. Use names that describe the task and identity.

Multiple sessions on one browser

Use multiple sessions when tasks should share the same login state but run independently:

browser-act --session inbox-check browser open <browser_id> https://example.com/inbox
browser-act --session report-export browser open <browser_id> https://example.com/reports

Both sessions share the browser's cookies and profile, but navigation and current page state are separate.

Privacy mode sessions

For stealth browsers with --private true, each session starts with a fresh fingerprint and empty profile:

browser-act browser create \
  --type stealth \
  --name "private-runner" \
  --desc "Fresh identity for one-off collection" \
  --private true

This avoids residue between jobs. The trade-off is that login state is not kept.

Session lifecycle

flowchart TD
  Open["Open"] --> State1["State"]
  State1 --> Act["Act"]
  Act --> State2["State again"]
  State2 --> Repeat{"More?"}
  Repeat -->|Yes| Act
  Repeat -->|No| Close["Close"]

Rules:

  • A session belongs to the agent or task that created it.

  • A session is tied to one browser.

  • One browser can have multiple sessions.

  • Session names must be unique.

  • Idle sessions may be reclaimed automatically after a period of inactivity.

List and close sessions:

browser-act session list
browser-act session close <session_name>

Commands that do not need a session

These commands operate outside a browser workspace:

  • browser list

  • browser create

  • browser update

  • browser delete

  • browser regions

  • browser list-profiles

  • session list

  • auth login, auth poll, auth set, auth clear

  • get-skills

  • report-log

  • feedback

  • stealth-extract

Best practices

Tip: Use descriptive session names such as pricing-us, login-check, or report-export. Close sessions when the task is complete.

Shared account work

Use multiple sessions when tasks should share one browser identity and login state.

Separate identities

Use separate browsers when tasks need separate accounts, regions, cookies, or proxies.

One-off jobs

Use privacy mode for work that should leave no persistent profile state.

Readable ownership

Name sessions by task and identity so agents and humans can understand what each session is doing.

Learn more

Browser Modes

Choose the right browser identity before running parallel work.

Designed for Agents

See how naming, selection, and safety rules help agents operate cleanly.

Command Reference

Look up browser and session management commands.

Did this answer your question?