Playwright MCP fails to launch when Chrome is already running on Windows

[MMM1970]

Bug Description

The Playwright MCP server (plugin:playwright) fails to launch a browser when Google Chrome is already running on Windows. Playwright is configured to use Chrome (channel: "chrome"), but Chrome on Windows does not support multiple simultaneous instances with different user data directories — the second launch attaches to the existing session and immediately exits.

Environment

• OS: Windows 11 (Build 26200)
• Claude Code: v2.1.37 (npm global install)
• Playwright MCP: @playwright/mcp@latest (v0.0.64)
• Chrome: v144.0.7559.133

Steps to Reproduce

1. Have Google Chrome open (normal browsing session)
2. Start Claude Code CLI
3. Use any Playwright MCP tool (e.g., browser_navigate, browser_take_screenshot)
4. Playwright tries to launch Chrome with its own --user-data-dir and --remote-debugging-port
5. Chrome detects the existing instance, prints "Opening in existing browser session", and exits

Error Output

browserType.launchPersistentContext: Failed to launch the browser process.

<launching> C:\Program Files\Google\Chrome\Application\chrome.exe --disable-field-trial-config ... --user-data-dir=C:\Users\bigfa\AppData\Local\ms-playwright\mcp-chrome-0e6d30e --remote-debugging-port=57745 about:blank
<launched> pid=25256
[pid=25256][out] Opening in existing browser session.
[pid=25256] <process did exit: exitCode=0, signal=null>

Expected Behavior

Playwright should be able to launch its own isolated browser instance even when Chrome is already running. Possible solutions:

1. Use Chromium instead of Chrome — Playwright's bundled Chromium can run independently alongside Chrome
2. Connect to the existing Chrome via CDP — Instead of launching a new process, connect to Chrome's existing remote debugging port
3. Use --new-window flag or other mechanism to coexist with the running Chrome instance

Workaround

Close all Chrome windows before using Playwright MCP tools, then reopen Chrome afterward. This is disruptive to the user's browsing session.

Notes

This is particularly problematic when both Playwright MCP and Claude in Chrome are configured, since Claude in Chrome requires Chrome to be running, while Playwright MCP requires Chrome to not be running — making them mutually exclusive on Windows.

[JTKretz]

Additional reproduction scenario: two simultaneous Claude Code sessions

I can reproduce this on demand with a simpler setup than having a personal Chrome window open. The trigger is two Claude Code CLI sessions both attempting to use the Playwright MCP server.

Steps to reproduce:

Open two Claude Code CLI sessions (e.g. two VSCode terminals running Claude Code)
In Session 1, ask Claude to use Playwright (e.g. navigate to a URL) — succeeds
In Session 2, ask Claude to use Playwright for any URL
Session 2 fails immediately with:

browserType.launchPersistentContext: Failed to launch the browser process.
[pid=61648][out] Opening in existing browser session.
[pid=61648]
Root cause observation:

Both MCP server instances attempt to launch Chrome with the same --user-data-dir:

--user-data-dir=C:\Users\Jeffrey\AppData\Local\ms-playwright\mcp-chrome-17b102f
Chrome's single-instance enforcement detects a running instance using that profile, delegates to it, and exits with code 0. Playwright interprets the immediate exit as a launch failure.

Environment:

OS: Windows 11 Enterprise 10.0.26100
Chrome: C:\Program Files\Google\Chrome\Application\chrome.exe
Claude Code: VSCode extension
Playwright MCP: @playwright/mcp
Suggested fix direction:

Each MCP server instance should use a unique --user-data-dir (e.g. by appending a process ID or random suffix) so concurrent sessions don't collide. Alternatively, using the bundled Chromium instead of system Chrome would sidestep the single-instance restriction entirely.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[aqilc]

I have the same exact problem. Has anyone found any solution or is there any way to get some help?

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.