Chrome Browser Multi-Instance Isolation (Part 1): Session Hijack, Config Conflicts, Memory Contamination

A Typical Chaos Scenario

Two AI agents running simultaneously. Agent A is filling an e-commerce checkout form — already on the payment page. Agent B opens a new tab in the same browser instance to scrape competitor prices.

Suddenly, Agent A's tab navigates to a completely unrelated page. The partially filled payment form is lost. Agent A errors out. Task failed.

This isn't hypothetical. agent-browser Issue #326 describes exactly this scenario: multiple agent-browser instances running simultaneously hijack each other's sessions.

Root Cause 1: Shared CDP Targets

Chrome DevTools Protocol is designed for one debugger controlling one browser. When you connect via CDP, all tabs (Targets) are visible to the debugger.

When two independent agent-browser instances connect to the same CDP port, they see the same Target list:

• Instance A's tab is visible to Instance B
• Instance B can operate on Instance A's tab
• Instance B closes Instance A's tab by accident → A's task fails

CDP port (localhost:9222)
    │
    ├── Target 1 (Tab A, used by Agent A)
    ├── Target 2 (Tab B, used by Agent B)
    └── Target 3 (blank page)
 
Agent A calls Target.attach → attaches to Target 1
Agent B calls Target.attach → attaches to Target 2
Agent B mistakenly closes Target 1 → Agent A's task fails

Root Cause 2: Shared localStorage and Cookies

Even if agents use different browser configurations pointing to the same user data directory, localStorage and cookies are shared. Agent A writes a token to localStorage. Agent B overwrites it in another task. Agent A's next operation fails due to invalid auth.

Same Chrome user data directory on disk
    │
    ├── Default Storage
    │   ├── localStorage (Agent A wrote token_A)
    │   └── Cookies (Agent A's session cookies)
    │
    ├── Agent B writes token_B → overwrites token_A
    │
    └── Agent A's next request uses expired token → auth failure

Root Cause 3: Memory Contamination

Multiple agents operating in the same browser process affect each other's performance. Agent A opens a JavaScript-heavy SPA consuming 500MB. Agent B's operations slow down due to GC pauses.

A subtler issue: JavaScript variables injected by Agent A's page can pollute the global scope, affecting script execution in Agent B's page.

Real Case: Playwright MCP 21-Hour Memory Leak

As analyzed previously, a long-running MCP session consumed 24.6GB virtual memory over 21 hours and 28 minutes. The core cause: each tool call creates BrowserContext/Page/Frame/JSHandle objects that aren't fully released.

With multiple agents sharing the same browser instance, the leak rate multiplies by N. A 16GB server can be exhausted within hours.

When This Happens

Three scenarios that most commonly trigger multi-agent isolation issues:

Scenario 1: Parallel CI/CD tests Multiple test cases run in parallel on the same CI runner. Each starts an agent-browser instance. All default to connecting to the same Chrome instance. Test A's tab gets closed by Test B.

Scenario 2: Multi-account management One agent manages multiple social media accounts, each in a separate tab. Cookies are shared. Account A's login gets overwritten by Account B's operations.

Scenario 3: Production concurrent task queues Multiple background tasks dispatched to nodes in the same browser cluster. Without session isolation, Tasks A and B can end up on the same browser instance, interfering with each other.

Quick Overview of Solutions

The next article details each approach with concrete implementation, costs, and pitfalls.