Why I Stopped Letting AI Agents Open Fresh Chrome Windows¶

The default configuration for browser-driving AI tools is broken for authenticated engineering work. Spawning an isolated Chrome instance in /tmp works when running stateless integration tests or inspecting public documentation, but using that same pattern for authenticated platforms triggers anti-bot checkpoints and destroys session state on every exit. This is why automated test software flags endanger primary credentials, and how attaching directly to a running browser session fixes both problems.

The Automation Infobar Problem¶

When an agent tool like chrome-devtools-mcp launches Chrome without arguments, it starts Puppeteer under the hood. Puppeteer creates a fresh user data directory in /tmp and launches the browser with automated testing flags.

The browser window opens with a distinct warning banner:

Chrome is being controlled by automated test software

For testing staging builds on localhost, this isolation is intentional. For operating against production SaaS platforms, it creates two immediate failures:

1. Session Amnesia: Every session starts with an empty cookie jar and no local storage. Navigating to GitHub or LinkedIn prompts for credentials every time.
2. The Automation Fingerprint: Chromium sets navigator.webdriver = true and enables the DevTools Protocol runtime domain. Anti-bot heuristics on modern platforms detect this flag immediately. Logging into a personal primary account from an automated test browser risks CAPTCHA loops, phone verification challenges, and account suspension.

In headless CI pipelines, test isolation is necessary and automated flags are harmless: tests run against disposable staging databases with mock credentials. For everyday engineering workflows that rely on authenticated sessions, that pattern breaks down. Forcing a primary engineering account into a temporary test harness triggers account verification locks and repetitive sign-in prompts.

Investigating the Local Setup¶

My workstation already runs BrowserOS, an agent-focused Chromium browser holding my active engineering logins. However, agent requests were bypassing it entirely and opening empty Chrome windows.

Inspecting listening TCP ports revealed the conflict:

lsof -nP -iTCP -sTCP:LISTEN | grep -E '9000|9010|9104|9110|9222'

Output:

BrowserOS 69481 ibtisam-iq   48u  IPv4 ... *:9010 (LISTEN)
BrowserOS 69481 ibtisam-iq   49u  IPv4 ... 127.0.0.1:9110 (LISTEN)
BrowserOS 72902 ibtisam-iq   56u  IPv4 ... *:9000 (LISTEN)
BrowserOS 72902 ibtisam-iq   57u  IPv4 ... 127.0.0.1:9104 (LISTEN)

The system had two browser installations with distinct responsibilities:

• PID 69481 (BrowserOS neo.app): Listening on port 9010. A standalone agent sandbox without personal credentials.
• PID 72902 (BrowserOS.app): Listening on port 9000 (MCP proxy) and port 9104 (Chromium DevTools Protocol). This was the primary daily browser with active sessions.

The global configuration (~/.gemini/config/mcp_config.json) pointed to port 9010. When that connection lagged or failed, the agent fell back to spawning the empty /tmp Chrome window.

Two Ports, One Browser¶

BrowserOS runs two distinct communication layers simultaneously:

Instead of allowing tools to spawn disposable child processes, both MCP servers can attach directly to the running application:

{
  "mcpServers": {
    "browseros-neo": {
      "_comment": "Connects to primary BrowserOS via MCP on port 9000. Opens new tabs in existing window.",
      "serverUrl": "http://127.0.0.1:9000/mcp"
    },
    "chrome-devtools-mcp": {
      "_comment": "Attaches to running BrowserOS via CDP on port 9104. Uses existing window with all active logins.",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--browserUrl",
        "http://127.0.0.1:9104"
      ],
      "command": "npx"
    }
  }
}

Passing --browserUrl http://127.0.0.1:9104 instructs chrome-devtools-mcp to connect to the existing CDP target rather than spawning a binary.

Under CDP, calling Target.createTarget creates a new tab inside the existing window by default. The tab opens in front of the operator, uses the existing browser profile, and keeps navigator.webdriver = false.

The Universal Chromium Pattern: Chrome, Brave, and Comet¶

While BrowserOS embeds a native MCP server on port 9000, standard Chromium browsers (Google Chrome, Brave, Comet) achieve the exact same persistent attachment through the Chrome DevTools Protocol.

Standard browsers disable remote debugging ports by default for security. Launching them with --remote-debugging-port=9222 binds the CDP interface to localhost:

# Google Chrome
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 &

# Brave Browser
/Applications/Brave\ Browser.app/Contents/MacOS/Brave\ Browser --remote-debugging-port=9222 &

# Comet Browser
/Applications/Comet.app/Contents/MacOS/Comet --remote-debugging-port=9222 &

Passing --browserUrl http://127.0.0.1:9222 to chrome-devtools-mcp connects the agent to that running instance. The agent opens new tabs in the active window, inherits existing logins, and avoids automated test flags.

(Note: Safari cannot use this pattern because it runs on WebKit rather than Chromium. It uses the WebKit Inspector Protocol instead of CDP, and Apple sandbox controls deliberately block external drivers from automating personal Safari sessions).

The Language Server Lifecycle Trap¶

Editing configuration files while an AI editor is running introduces a subtle caching issue:

Opening a new chat thread does not reload background MCP servers.

Modern AI developer environments maintain a persistent Language Server daemon across chat threads. Sockets opened at daemon startup remain pinned to old ports. A new chat thread will continue routing requests to stale endpoints until the editor process terminates completely.

Fully quitting the editor (Cmd + Q) and relaunching resets the daemon sockets, establishing live connections to ports 9000 and 9104.

Two operational tracks: interactive agent vs headless CI¶

This architecture establishes a clear boundary between interactive engineering and synthetic testing:

flowchart TD
    Task("Browser Task") --> Check{"Requires Authenticated Identity?"}

    Check -- Yes --> Track1["Track 1: Live Browser Attachment"]
    Track1 --> B1["BrowserOS or Running Chrome (Port 9000 / 9104)"]
    B1 --> B2["Active user session (navigator.webdriver = false)"]
    B2 --> B3["GitHub, LinkedIn, and live engineering tabs"]

    Check -- No --> Track2["Track 2: Ephemeral Sandbox"]
    Track2 --> P1["Puppeteer or Playwright runner"]
    P1 --> P2["Disposable /tmp directory or container"]
    P2 --> P3["CI/CD test suites, mock data, staging validation"]

1. Track 1 (Interactive Engineering Work): Driven through BrowserOS or live Chrome attachment. The operator sees tabs open in real time, requests reuse authenticated sessions, and primary credentials remain protected from automation flags.
2. Track 2 (Synthetic CI & Automated Testing): Driven through headless runners in disposable environments (/tmp profiles or CI containers) against staging endpoints. If a test crashes or corrupts local storage, no production session is affected.

Connecting agent tooling directly to an active browser instance eliminates repetitive manual logins while protecting primary engineering accounts from automated test flags.