[MCP] Stdio server should dispose browser when stdin closes

[qingye-lab]

Context

This came from the closed PR #41656. The request there was to start by filing an issue.

While investigating long-lived browser automation processes on macOS, I noticed that the MCP stdio server wires process.stdin end to transport.close(), but not close. Some MCP client disconnect paths can surface as stdin close, not just EOF.

Current behavior

For stdio transport, Playwright currently relies on:

• process.stdin.on('end', () => void transport.close()) in packages/playwright-core/src/tools/utils/mcp/server.ts
• the broader exit watchdog, which also watches stdin close and calls graceful browser cleanup during process exit

That means stdin close is not routed through the MCP server transport close path. Backend disposal can rely on the process-level watchdog instead of the normal server close path.

Expected behavior

When stdin closes, the stdio transport should close as well, so the existing MCP server close handler disposes the backend and closes the launched browser promptly. The close path should be idempotent because both end and close may fire.

Suggested fix

Handle both stdin events with the same idempotent close function, e.g. close the StdioServerTransport on both end and close.

The regression test I used in PR #41656 launches the MCP server with --isolated, calls browser_navigate, closes the stdio client, and asserts that the debug log includes close browser.

Validation from the prototype PR

In the prototype branch from PR #41656, these checks passed locally:

• PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1 npm ci
• npm run build
• npm run tsc
• npm run test-mcp -- launch.spec.ts --project=chrome

Environment

• macOS
• Node.js v24.x
• Playwright MCP / playwright-core main branch when prototyping the fix

[yury-s]

The browser already gets closed when stdin closes — setupExitWatchdog() listens on stdin's close event and runs gracefullyCloseAll() before exiting, so nothing is leaked. Before changing anything, could you share a concrete repro where this actually causes a problem (leaked process, hung server, cleanup that doesn't run), and which MCP client/OS emits close without a preceding end?

[qingye-lab]

Thanks for checking. You are right that I do not currently have a concrete repro for the stdio-specific claim where close happens without a preceding end and the browser cleanup does not run.

The concrete observation that led me here is slightly different: on macOS I can see a long-lived Playwright CLI daemon process that has been reparented to PID 1 and still owns a headless Chrome child, e.g.

node .../playwright-core/lib/entry/cliDaemon.js default   PPID=1
/Applications/Google Chrome.app/... --user-data-dir=/var/folders/.../playwright_chromiumdev_profile-... --remote-debugging-pipe

Environment where I observed that:

• macOS 26.5.1 arm64
• Node v24.x
• Codex Desktop / Playwright MCP tooling

Looking at the code again, that concrete process is cliDaemon.js, not the MCP stdio server path in this issue. So I agree this issue as filed does not establish that setupExitWatchdog() fails for stdio stdin close. I will investigate the CLI daemon case separately and only file a more focused issue/PR if I can isolate a minimal repro for that lifecycle problem.

Feel free to close this stdio issue if that is the right call.

[yury-s]

Cli daemon is expected to keep the browser open until you close the session.