#42973·Playwright

[MCP]: --extension background mode: let several agents use the logged-in browser without taking the screen

Author: isaachorowitzCreated Sep 28, 2026Updated Sep 28, 2026

What's going on?

We run several coding agents (Claude Code, Codex, Cursor) against --extension on macOS so they can use the browser the person is already logged into. Opening this as an issue since Discussions aren't enabled here. With more than one agent at a time, the extension's connect flow gets in the way of the person using the machine:

  1. On connect the extension activates the chosen tab and focuses its window (chrome.tabs.update({active: true}) and chrome.windows.update({focused: true}) in _connectTab), and Page.bringToFront / Target.activateTarget do the same mid-task. Chrome comes to the front and can switch the macOS Space while the person is typing in another app.
  2. Agent tabs live in the person's own windows. Only the active tab of a window gets animation frames and trusted input, so an agent tab behind the one they are looking at can't be driven reliably, and the one they are looking at gets navigated under them.
  3. Each client gets a tab group, and Chrome keeps closed group records, so the tab-group menu grows with every agent task.
  4. The pairing token ends up in every agent's MCP config through PLAYWRIGHT_MCP_EXTENSION_TOKEN.

We worked around all four in a fork of the extension at d5a185a (the multi-client commit) and have used it daily since. What worked:

  • Each client gets a background tab (chrome.tabs.create({active: false})) inside a small pool of dedicated, never-focused normal windows, up to 16 tabs per window. A per-window scheduler activates one client's tab at a time with chrome.tabs.update({active: true}), only while that client has a command in flight. That call changes the tab strip only; it never focuses the window.
  • Page.bringToFront and Target.activateTarget are no-ops for these clients. No tab groups: exact tab IDs give each client ownership and cleanup.
  • The windows are never minimized (a minimized window gets no animation frames and no trusted input), and on macOS Chrome runs with --disable-backgrounding-occluded-windows so covered windows keep rendering.
  • The MCP server reaches the extension through a native messaging host, so no agent config holds the token.

On Chrome 154 and macOS this ran 24 simultaneous clients across four windows with trusted clicks and typing, no focus or Space change, and exact cleanup on browser_close.

Would you be open to a background option for --extension along these lines? Even the first piece would remove most of the pain: an option that skips activating and focusing on connect and makes bringToFront a no-op, and a mode where the extension creates the client's tab in a window it owns instead of asking the person to pick one. Happy to split this into smaller issues or send PRs for whatever fits your plans.

The fork, with design notes and the list of Chrome behaviors we ran into along the way: https://github.com/ZipLyne-Agency/agent-lanes (see docs/why.md and extension/UPSTREAM.md).

Version

@playwright/mcp 0.0.79; extension forked from d5a185a (0.3.0). The current upstream extension (0.4.0) still activates and focuses on connect and groups tabs per client.