@playwright/mcp 0.0.78 --extension: preflight validation and browser launch can target different Chrome profiles #41916

Environment

• OS: Windows 11 Pro, build 10.0.26200
• Claude Code: 2.1.212
• Chrome profile: non-default, custom profile directory (not Default)
• Playwright MCP Bridge extension: v0.2.1 (installed from Chrome Web Store)
• @playwright/mcp: 0.0.78 (resolved via npx @playwright/mcp@latest --extension)
• MCP client registration (Claude Code mcpServers):

  {
    "playwright-extension": {
      "type": "stdio",
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--extension"],
      "env": {}
    }
  }

• No PLAYWRIGHT_MCP_EXTENSION_TOKEN set in server env (extension popup surfaces a token for this purpose, not yet used).

Expected behavior

On the first tool call (e.g. browser_tabs), the extension should either show a connect/share/tab-selection dialog, transition its popup status away from "No clients are currently connected," or log a connection attempt in its service worker console.

Actual behavior

• Claude Code reports the playwright-extension MCP server as connected at the stdio/process level.
• The underlying @playwright/mcp --extension Node process is confirmed alive, listening on a loopback port (::1:<ephemeral port>, State: Listen, zero Established connections at any point observed).
• Every browser tool call (browser_tabs, browser_snapshot, browser_take_screenshot, browser_navigate) hangs for approximately 120 seconds with no error returned.
• Extension popup permanently shows: "No clients are currently connected. You can connect from the Playwright CLI or MCP server by passing the --extension flag. Set this environment variable to bypass the connection dialog: PLAYWRIGHT_MCP_EXTENSION_TOKEN=..."
• No connect/share dialog ever appears in the browser, across dozens of repeated tool calls over an extended session.
• chrome://extensions shows no runtime errors for the extension.

Reproduction steps

1. Install Playwright MCP Bridge extension (v0.2.1) from the Chrome Web Store into a non-default Chrome profile directory (not Default).
2. Register the MCP server in Claude Code with the config shown above (--extension flag, empty env).
3. Start Claude Code; confirm the playwright-extension MCP server shows as connected.
4. Invoke any browser tool, e.g. browser_tabs (action: "list").
5. Observe: call hangs approximately 120 seconds, no dialog appears in the browser, extension popup remains on "No clients are currently connected."
6. Repeat with browser_snapshot, browser_take_screenshot — identical hang every time.
7. During an active hanging call from step 4 or step 6, simultaneously inspect chrome://extensions → Details → Inspect views → service worker console and network panel.

Evidence collected

• Extension popup, Service Worker Console, Service Worker Network panel, and the MCP server process state were all observed simultaneously during active hanging tool calls: Console stayed completely empty, Network panel showed zero entries, popup text never changed, and the server process remained in Listen-only state throughout. No observable trace of a connection attempt reaching the extension runtime was found at any layer during the hang.
• Process tree confirms the --extension flag reaches the final cli.js invocation unmodified through the full launch chain (cmd.exe → node.exe (npx) → cmd.exe (playwright-mcp shim) → node.exe (cli.js --extension)).
• Get-NetTCPConnection -OwningProcess <pid> on the final node process shows exactly one socket (Listen, loopback, zero Established), checked both before and during an active hanging tool call.
• A separate, independently-launched @playwright/mcp instance without --extension (a different MCP server registration active in the same Claude Code session) works correctly and instantly for identical tool calls — ruling out a general Node/network-stack problem on this machine.

Architectural analysis

• The --extension flag is verified present at every layer: MCP client config → spawned process command line.
• A correctly working MCP setup exists on the same machine at the same time (the non-extension provider), ruling out systemic Node/npm/network/firewall issues.
• The extension reports zero runtime errors in chrome://extensions.
• The server process is demonstrably alive and listening — this is not a crash or failed launch.
• No custom env, proxy, or non-standard networking is involved (env: {}, default loopback).
• Source-code analysis of @playwright/mcp 0.0.78 / playwright-core 1.62.0-alpha (packages/playwright-core/src/tools/mcp/extensionContextFactory.ts, cdpRelay.ts) reveals a mechanism that can produce this exact symptom on a cold Chrome start. createExtensionBrowser()'s preflight check, isPlaywrightExtensionInstalled(), succeeds as soon as the Bridge extension is found in any profile named Default or Profile N — it returns a boolean only, discarding which profile matched. The subsequent launch, in _openConnectPageInBrowser(), passes neither --user-data-dir nor --profile-directory, so Chrome opens whatever profile it considers last-used, independent of which profile satisfied the preflight check.
• During the investigation, it was confirmed that the extension is installed in the custom profile and in a second, standard-named profile, while Chrome's Local State records Default — which lacks the extension — as last_used. Preflight can therefore pass while Chrome opens an unrelated profile, matching the complete absence of any connection trace observed above. This has not been confirmed as the root cause here, but it offers a code-backed explanation for why the failure is silent rather than the loud preflight rejection in --extension preflight only checks User Data\\Default, so installed bridge in active non-default Chrome profile is reported as missing playwright-mcp#1577.

Related issues

• Bridge extension stays 'No MCP clients are currently connected' with --extension mode (macOS, Chrome stable) playwright-mcp#1571 — same symptom category (permanent "No clients are currently connected," tool calls time out, no dialog appears); closed as environment-specific/unreproduced, no root cause identified.
• --extension preflight only checks User Data\\Default, so installed bridge in active non-default Chrome profile is reported as missing playwright-mcp#1577 — Windows, non-default Chrome profile causes --extension preflight to fail to detect an installed bridge extension; closed, but describes a loud failure rather than a silent hang.
• Bug: Playwright MCP Bridge Extension Cannot Connect to MCP Server (v0.0.40) playwright-mcp#1090 — maintainer clarified the connect dialog should trigger "first time when MCP server needs to connect to a page in the browser to handle the command"; in this report, that trigger never fires despite dozens of qualifying tool calls.

Question for maintainers

createExtensionBrowser()'s preflight check and _openConnectPageInBrowser()'s launch step operate on independent profile assumptions — the former validates against any Default/Profile N directory, the latter launches whatever profile Chrome opens by default. Is this architectural separation intentional, or should the launch step be tied to the profile that satisfied preflight validation, for example via an explicit --profile-directory option?