{{ message }}
Repository navigation
MCP server crashes when downloading files with persistent profile on Windows #42831
Description
Environment:
- OS: Windows 10 Enterprise
- Node.js: v22.x
- @playwright/mcp: latest (v0.0.81)
- Claude Code (VSCode extension)
Description:
When using Playwright MCP with a persistent profile (default behavior), any file download operation causes the MCP server to crash with error MCP error -32000: Connection closed.
Steps to reproduce:
- Install Playwright MCP via Claude Code:
claude mcp add playwright npx @playwright/mcp@latest - Navigate to any website with a download button (e.g., Moka HR system's interview recording download)
- Click the download button (either programmatically or manually in the opened browser)
- Observe the MCP server crashes with
MCP error -32000: Connection closed
Expected behavior:
The download should complete successfully without crashing the MCP server.
Actual behavior:
- MCP server process exits when download starts
- The file is still downloaded successfully to
~/Downloads/ - MCP connection is lost, requiring reconnect
Workaround:
We currently handle this by:
- Accepting the crash as expected behavior
- Finding the downloaded file (often with
.tmpextension) in~/Downloads/ - Waiting for MCP to reconnect automatically
- Continuing the workflow
Additional context:
- This happens with any download operation, not just specific websites
- The download itself completes successfully; only the MCP server crashes
- This seems related to how Playwright MCP handles download events with persistent profiles
- Non-persistent profiles may not have this issue, but we need persistent profiles to maintain login state
Related issues:
- Mcp error -32000: Connection closed playwright-mcp#658 (similar connection closed error, but different cause - Windows npx invocation)
Activity
zhigangliu-bot commentedon Sep 16, 2026
Update: Root Cause Identified
After further testing, I found the root cause is accumulated profile state rather than a fundamental bug in Playwright MCP.
Investigation Results
Crash dump files found: 8 crash dump files in
%LOCALAPPDATA%\ms-playwright-mcp\mcp-chrome-xxx\Crashpad\reports\Timeline analysis:
Solution that worked: Deleting the entire
ms-playwright-mcpdirectory:rm -rf "%LOCALAPPDATA%\ms-playwright-mcp"After this, downloads work normally without crashes.
Root Cause
The persistent profile accumulates state over time (crash reports, cache, etc.). When this state becomes corrupted or reaches a certain threshold, it triggers crashes during download operations.
Suggested Improvements for Playwright MCP
Workaround for Users
If you encounter this issue, try deleting the
ms-playwright-mcpdirectory to reset the profile state. Note that you'll need to re-login to websites after this.zhigangliu-bot commentedon Sep 16, 2026
Further Testing: Crash Reports Not the Cause
I tried deleting the crash reports directory:
The crash still happens. This confirms the issue is not caused by accumulated crash reports.
Additional Finding
The crash occurs even when manually clicking the download button in the Playwright-opened browser. This means the issue is not with Playwright MCP tool calls, but with the browser instance itself when handling downloads.
Workaround
The file is still downloaded successfully to
~/Downloads/(usually as a.tmpfile) despite the crash. We can:.tmpfileThe crash is annoying but doesn't prevent the download from completing.
zhigangliu-bot commentedon Sep 16, 2026
Solution Found: Delete the Entire Profile Directory
After extensive testing, I found the solution:
What Works
Deleting the entire
ms-playwright-mcpdirectory:rm -rf "%LOCALAPPDATA%\ms-playwright-mcp"After this, downloads work normally without crashes. I tested downloading twice in a row - both succeeded without crashes.
What Doesn't Work
Crashpad\reports\directory - crashes still happenRoot Cause
The issue is caused by accumulated state in the persistent profile directory. Something in the profile (not just crash reports) becomes corrupted or reaches a problematic state that triggers crashes during downloads.
Recommendation for Users
If you encounter download crashes with Playwright MCP:
%LOCALAPPDATA%\ms-playwright-mcp(Windows) or~/.playwright-mcp(Linux/macOS)Suggested Fix for Playwright MCP
Consider implementing:
zhigangliu-bot commentedon Sep 16, 2026
Critical Finding: Profile State After Browser Close Triggers Crash
I discovered the exact trigger:
Steps to Reproduce
ms-playwright-mcpdirectoryWhat This Means
The issue is triggered by something that happens during browser shutdown:
Workaround Options
~/Downloads/Possible Root Cause
Something in the browser shutdown sequence corrupts or sets a state that breaks download handling when the browser restarts with a persistent profile. This could be:
This is a bug in how Playwright MCP handles persistent profile lifecycle on Windows.
zhigangliu-bot commentedon Sep 17, 2026
Summary and Request for Official Response
Problem Summary
This is a critical issue affecting Windows users who need persistent profiles to maintain login states. The issue:
Current Workarounds
Investigation Findings
Based on extensive testing:
Questions for Maintainers
Suggested Fixes
Possible approaches that could help:
This issue significantly impacts the usability of Playwright MCP for production workflows on Windows. Any guidance or fix would be greatly appreciated!
github-actions commentedon Sep 21, 2026
Hi, I'm the Playwright bot and I took a first look at this on Windows.
Couldn't reproduce the crash. On a Windows runner with real Chrome and the default persistent profile, I ran your exact trigger — download, close the browser, reopen, download again — on
@playwright/mcp0.0.81 (the version you reported) and 0.0.82, headed and headless. The download completed and the MCP server stayed up every time.One detail in your report points somewhere useful though: you say the file lands in
~/Downloads, often as a.tmp. When the MCP server handles a download, Playwright intercepts it and saves it into the MCP output dir — in my runs it was.playwright-mcp\hello.txt, never~/Downloads. A file in~/Downloadsmeans Chrome's own download manager wrote it, i.e. the download was never handed to Playwright. Combined with the Crashpad dumps you found, that reads as the Chrome process itself dying, withMCP error -32000: Connection closedbeing the downstream symptom rather than the cause.So the two questions I'd need answered to get further:
--browser chromeagainst an existing profile, the browser extension, or a CDP endpoint — rather than letting it launch its own persistent profile? That would explain downloads going to~/Downloads..dmpfiles from%LOCALAPPDATA%\ms-playwright-mcp\mcp-chrome-*\Crashpad\reports\, plus the MCP server's stderr withDEBUG=pw:browser*set? The dump will say whether Chrome crashed on its own.What I ran
windows-latest), Node v24.20.0, Google Chrome fromC:\Program Files\Google\Chrome\Application\chrome.exe@playwright/mcp@0.0.81(as reported) and@playwright/mcp@0.0.82%LOCALAPPDATA%\ms-playwright-mcp(confirmed created and reused)--output-dirpointing at a non-directory: both 0.0.81 and 0.0.82 surfacedENOTDIRas a normal tool error and the server stayed up — so a failedsaveAsisn't taking the process down eitherContent-Disposition: attachment.playwright-mcp\hello.txt, not~/DownloadsI'm a first pass, not the final word here — a crash dump would settle it quickly.
Triaged on Windows by the Playwright bot - agent run
chore: mark v0.0.83 (#1779)
chore: mark v0.1.22 (#473)
chore(deps): update all non-major dependencies (#199)
chore(deps): update dependency @playwright/mcp to v0.0.83 (#1108)
chore: mark v0.0.83 (microsoft#1779)
Update agent CLIs
chore(deps): update dependency @playwright/mcp to v0.0.83 (#3186)
chore(deps): update dependency @playwright/mcp to v0.0.83 (#64)