--extension can hang indefinitely when connect.html lands in another Chrome profile #1732

Summary

With --extension on a multi-profile Chrome setup, the first browser tool call can wait indefinitely when connect.html lands in a different profile from the one whose extension token was configured.

This is especially reproducible when a person is using Chrome at the same time: starting a fresh MCP/client session resets the stuck server-side promise, but does not remove the race over which Chrome profile/window receives the connect page.

Environment

• macOS, Chrome with multiple profiles
• One account per Chrome profile
• Playwright extension installed in multiple profiles, with a different extension token per profile
• @playwright/mcp 0.0.79
• Invocation uses --extension

Observed behavior

On the first browser tool call, MCP launches Chrome with a chrome-extension://.../connect.html URL and waits for _extensionConnectionPromise.

When that URL is opened in the last-active Chrome profile/window rather than the intended profile:

1. The extension token does not match.
2. The WebSocket connection is never established.
3. No extension disconnect event fires because there was no connection to disconnect.
4. The promise has no timeout, so the tool call neither succeeds nor returns an explicit error.
5. Retrying in the same session waits on the same unresolved promise.

In one run today this failed three times in a row:

1. Initial tool call in an interactive session.
2. Retry in the same session.
3. A new client session (claude -p) and a new MCP server session.

The new session cleared the previously stuck server state, but the connect page again landed in the wrong profile while Chrome was being actively used.

Expected behavior

Either:

1. Allow the extension profile to be selected explicitly, for example with --profile-directory / --browser-profile (or a config/environment equivalent), and pass it through deterministically; or
2. Put a finite timeout around the extension connection wait and return a clear error such as "Playwright extension did not connect; check the selected Chrome profile and extension token."

Ideally both would be supported. Explicit profile selection prevents the race; a timeout makes remaining failures diagnosable and lets the client recover.

Why this differs from related reports

Related: #1712, which fixed false-positive profile detection caused by leftovers from an uninstalled extension and also requested explicit profile selection.

This case does not depend on uninstall leftovers: the extension is genuinely installed in multiple profiles. The ambiguity is therefore real, and a human changing the active Chrome profile can make repeated fresh sessions lose in the same way.

Operational impact

A client-level 120-second timeout only stops the caller from waiting; it does not resolve the server-side connection promise. Without an explicit profile selector or a server-side timeout/error, the session is effectively unrecoverable and the next fresh session can immediately hit the same race again.