[MCP]: Exact alpha `playwright` pin in @playwright/mcp breaks lockfile-based supply-chain pinning in mixed codebases

[dbartholomae]

(This is a packaging/dependency-resolution issue, not specific to any MCP client — it occurs at npm/pnpm install time, before the server is ever invoked.)

This is a follow-up to microsoft/playwright-mcp#917, which was closed with:

We don't yet have a story for interoperable Playwright and Playwright MCP… it'll always be the latest version. That makes your scenario of the exact match niche until we hear more requests of such integration.

Here's one more request, with a motivation that's distinct from the type-incompatibility angle in #917 / microsoft/playwright-mcp#1113 and the browser-build mismatch in microsoft/playwright-mcp#1091: supply-chain integrity.

Why "latest, always" conflicts with a security-pinned codebase

We pin every dependency — including MCP packages — through the lockfile and review version bumps, specifically to reduce supply-chain attack surface. We can't run MCP tools off a floating "latest"; the resolved versions have to be committed and audited. That's fundamentally at odds with @playwright/mcp requiring whatever alpha is newest.

The pin doesn't stay contained to the MCP

@playwright/mcp doesn't just depend on an alpha playwright/playwright-core — it pins an exact alpha (e.g. playwright@1.61.0-alpha-1781023400000), and that pin leaks into unrelated parts of the dependency tree via peer resolution:

• @vitest/browser-playwright declares playwright: "*" as a (non-optional) peer.
• pnpm satisfies that peer with the only standalone playwright in the tree — the exact alpha dragged in by @playwright/mcp.
• That alpha pins Chromium build 1226, while the rest of our repo runs stable @playwright/test@1.60.0 (Chromium build 1223), which is what playwright install provisions.
• Result: in a fresh CI environment our Storybook (vitest browser-mode) tests can't launch a browser, because the build the alpha wants was never installed.

So the alpha pin isn't limited to the agentic-loop/IDE use case it was justified by in #917 — through transitive peer resolution it forces an alpha Chromium onto a stable Playwright test suite living in the same lockfile.

What would help (any of)

1. A @playwright/mcp release line that depends on a stable playwright/playwright-core (even if it lags the bleeding edge), so security-pinned consumers have a non-alpha option; or
2. Widening the dependency to a range that lets a pnpm/npm overrides align playwright with the stable version already in the consumer's lockfile, without breaking the MCP; or
3. A documented, supported override recipe for keeping a single, stable, lockfile-pinned playwright/playwright-core across @playwright/mcp + @playwright/test + @vitest/browser-playwright.

We currently work around it with pnpm.overrides forcing playwright/playwright-core to stable 1.60.0, but per #917 that's a fragile workaround rather than a supported path — and it's exactly the kind of unreviewed version-coercion our supply-chain policy is trying to avoid.

Version

@playwright/mcp 0.0.76 (pins playwright 1.61.0-alpha-1781023400000); repo otherwise on @playwright/test 1.60.0

[github-actions]

Hi, I'm the Playwright bot and I took a first look.

Confirmed — every fact in this report checks out against the published packages. @playwright/mcp pins an exact alpha playwright/playwright-core, that alpha pins a newer Chromium than the stable line, and a playwright: "*" peer lets the alpha satisfy unrelated parts of the tree. This is a real, reproducible-from-metadata supply-chain concern, not a misunderstanding. It's a design/policy call for the maintainers, so I'll lay out what I verified and leave the decision to them.

What I confirmed

• @playwright/mcp@0.0.76 → playwright@1.61.0-alpha-1781023400000 and playwright-core@1.61.0-alpha-1781023400000 (exact pins).
• The current @playwright/mcp@0.0.77 does the same with 1.62.0-alpha-2026-06-29 — so there's still no stable-tracking release line, the pin just rolls forward to the next alpha.
• Chromium build mismatch is real: stable playwright-core@1.60.0 ships Chromium 1223; the alpha 1.61.0-alpha-1781023400000 ships Chromium 1226.
• @vitest/browser-playwright@4.1.9 declares playwright: "*" as a (non-optional) peer, which is exactly what lets the alpha standalone playwright get hoisted to satisfy it — pulling Chromium 1226 into a repo whose playwright install only provisioned 1223.

So the chain you describe — exact alpha pin → * peer resolution → alpha Chromium forced onto a stable test suite in the same lockfile — holds up end to end.

What I ran

npm view @playwright/mcp@0.0.76 dependencies
#   playwright: 1.61.0-alpha-1781023400000
#   playwright-core: 1.61.0-alpha-1781023400000
npm view @playwright/mcp version            # 0.0.77
npm view @playwright/mcp dependencies
#   playwright: 1.62.0-alpha-2026-06-29
#   playwright-core: 1.62.0-alpha-2026-06-29

# Chromium build per browsers.json
playwright-core@1.60.0                  -> chromium 1223
playwright-core@1.61.0-alpha-1781023400000 -> chromium 1226

npm view @vitest/browser-playwright peerDependencies
#   { vitest: '4.1.9', playwright: '*' }

On the three options you list: (1) a stable-tracking @playwright/mcp line and (3) a documented override recipe are both packaging/release-process decisions rather than code changes, and they're owned by us — the @playwright/mcp release lives in microsoft/playwright-mcp, but that's our repo, so no need to refile anywhere. I can't make the policy call on whether to ship a stable line; I'm just confirming the problem is exactly as stated and well-motivated.

One concrete question to help the maintainers scope it: is a documented, supported overrides/pnpm.overrides recipe (option 3) enough for your supply-chain review process, or do you specifically need a published stable-tracking release (option 1) so there's nothing to coerce in the first place?

_{— triaged by the Playwright bot · run}

[dbartholomae]

Thanks for the thorough confirmation — that matches exactly what we see. Short answer: option 1 (a stable-tracking release line) is what actually resolves this for us, and option 2 (a widened range we can align via lockfile, e.g. >=1.60.0) would work just as well — both leave a single stable playwright/playwright-core that's a vendor-tested combination, with nothing for us to coerce. A documented override recipe (option 3) is only an interim fix: auditability isn't the blocker (pnpm.overrides are committed and show in the lockfile diff), but an override pins @playwright/mcp@X against a playwright it doesn't declare support for, so the day they drift it produces a tree that installs cleanly but is silently broken — exactly the failure mode our supply-chain policy exists to catch — and it has to be re-verified on every MCP bump as the pinned alpha rolls forward. So we'd rank it 1 ≈ 2 ≫ 3, with option 3 acceptable only if the documented recipe is paired with an explicit "MCP version X is supported against stable playwright Y" compatibility statement.

[pavelfeldman]

Stable Playwright versions have npx playwright cli that is equivalent to playwright-cli, so you can add brief instructions to your agent to use it and it should work fine.

[dbartholomae]

Thanks! So the MCP is not meant to be used in any contexts that care about security, and instead the CLI should be used in these cases?