feat(mcp): add --profile-dir-name to select the Chrome profile in extension mode

[Yury Semikhatsky (yury-s)]

Summary

• When the extension is installed in several Chrome profiles, the connect page opens in the last used one, which is not necessarily the profile the token belongs to. New --profile-dir-name <name> option (or PLAYWRIGHT_MCP_PROFILE_DIR_NAME) names the profile directory in the user data dir, the last component of "Profile Path" at chrome://version, and launches that profile explicitly via --profile-directory.
• The selected profile is verified to have the extension installed, the error names the profile directory.
• Documented in the extension README next to the per-profile token instructions.

References microsoft/playwright-mcp#1732

[github-actions]

Test results for "MCP"

1 failed
❌ [firefox] › mcp/cli-devtools.spec.ts:84 › request shows full request and response details @mcp-windows-latest-firefox

8274 passed, 1371 skipped

---

Merge workflow run.

[github-actions]

Hi, I'm the Playwright bot and I took a first look at the CI failures here.

🟢 The one failure is a pre-existing flake — this PR is clear

The only red is mcp/cli-devtools.spec.ts:84 › request shows full request and response details on mcp-windows-latest-firefox. It's a long-standing flake on that exact bot, not something this PR touched.

Details

This PR adds --profile-dir-name for MCP extension mode — it only touches tools/mcp/ extension wiring (browserFactory.ts, config.ts, extensionContextFactory.ts, program.ts, utils/extension.ts) and tests/extension/. The failing test exercises the requests/request CLI devtools command, a code path the diff never reaches.

Pre-existing flake / infra

• [firefox] › mcp/cli-devtools.spec.ts:84 › request shows full request and response details — the assertion expect(match).not.toBeNull() fails because the POST /api request hadn't shown up in the requests list yet: a timing race, not a logic error. Across the test-results DB this test flakes only on mcp-windows-latest-firefox: 10 failures in 2114 firefox runs (~0.5%), and green on every other browser (webkit 0/2161, chrome 0/2202, chromium 0/2153). The failures land on unrelated SHAs — PRs feat(chromium): roll to r1236 #42038, test(filechooser): allow exact one second lastModified rounding #42145, chore: remove experimental component testing #42168, chore(recorder): render highlights via the shared element highlight #42253, chore(highlight): resolve highlights periodically in HighlightController #42277, Revert "feat(routeFromHar): add interceptAPIRequests option (#41294)" #41964, fix(mcp): time out extension connection when a token is passed #42525, plus several push runs — so the PR can't be responsible.

_{Triaged by the Playwright bot - agent run}