[Feature Request] CDP BrowserContext support for cookie-isolated parallel sessions

[nathanvale]

Problem

When multiple agents connect to the same Chrome instance via --auto-connect or connect <port>, all sessions share the default BrowserContext. This means cookies, localStorage, and sessionStorage leak between sessions.

The --session flag provides tab-namespace isolation (each session tracks its own active tab), but does not create a CDP Target.createBrowserContext — so there is no storage isolation.

This is the root cause behind #86, #326, and #896 when agents use --auto-connect mode. PR #899 addresses the daemon-mode case (separate --profile per session), but --auto-connect has no equivalent fix.

Use Case

I run multiple AI agents against one real Chrome instance (launched with --remote-debugging-port=9223). Each agent handles a different service:

• Agent A: university admin panel (*.monash.edu)
• Agent B: personal cloud admin (*.google.com)
• Agent C: infrastructure (*.tailscale.com)

Today this works because the domains don't overlap — browser same-origin policy provides natural isolation. But if two agents need to interact with the same domain using different credentials (e.g., two Google accounts, or staging vs production on the same host), cookies collide and the second login overwrites the first.

Proposal

Expose CDP Target.createBrowserContext via a new --context <name> flag (or --incognito). When present, agent-browser would:

1. Call Target.createBrowserContext({ disposeOnDetach: true }) on the browser-level CDP session
2. Create new tabs within that context via Target.createTarget({ browserContextId: ... })
3. Scope all session commands to pages within that context
4. Dispose the context on close (or rely on disposeOnDetach)

Proposed CLI surface

# Create an isolated context connected to running Chrome
agent-browser --session work --context work connect 9223
agent-browser --session work open https://admin.example.com

# Separate isolated context, same Chrome, different cookies
agent-browser --session personal --context personal connect 9223
agent-browser --session personal open https://admin.example.com

# Cookies are fully isolated between contexts

Why createBrowserContext over separate profiles

Approach	Cookie isolation	Window count	Chrome processes	Startup time
Separate --profile per session	Full	N windows	N processes	Slow (Chrome launch per session)
CDP createBrowserContext	Full	1 window	1 process	Fast (context creation is ~5ms)

CDP BrowserContexts are the same mechanism Playwright and Puppeteer use for parallel isolated sessions. Tabs from different contexts can share one Chrome window — the context is a storage boundary, not a windowing boundary.

What This Enables

• True parallel multi-agent automation against one Chrome window
• Cookie-isolated sessions without window proliferation
• disposeOnDetach auto-cleans contexts when agents disconnect (no orphaned state)
• Parity with Playwright's browser.newContext() for users migrating from Playwright-based setups

Environment

• agent-browser v0.23.0
• Chrome v146.0.7680.165 (real Chrome, --remote-debugging-port)
• macOS Darwin 25.3.0

Related Issues

• Support for Multi Session #86 — Support for Multi Session
• Multiple agents running agent-browser appear to hijack each other #326 — Multiple agents hijacking each other
• [Bug] Multiple --session daemons sharing same --profile connect to single Chrome, causing tab accumulation and navigation timeout #896 — --session daemons sharing same --profile
• Fix Chrome instance collision by scoping profiles to session IDs #899 — Fix: scope profiles to session IDs (daemon mode only)
• Session close does not kill daemon — stale page contexts persist across sessions #1028 — Session close does not kill daemon (BrowserContext suggested as option 2)

Happy to provide more details or help with testing.

[mvanhorn]

Implemented in #1114 - adds the --context <name> flag following your design. Uses Target.createBrowserContext({ disposeOnDetach: true }) and passes browserContextId to all Target.createTarget calls.