Repository navigation
Filesystem MCP writes hang when launched via npx -y; reliability improves with pinned global install #4026
Closed as not planned
Description
Environment:
- macOS [your version — Sonoma, Sequoia, whatever]
- Claude Desktop [Help > About Claude Desktop > version]
- Node.js v22.18.0
- Filesystem MCP [version from
npm list -g @modelcontextprotocol/server-filesystem]
Reproduction:
- Configure Filesystem MCP in claude_desktop_config.json using
command: "npx", args: ["-y", "@modelcontextprotocol/server-filesystem", <dirs>] - Restart Claude Desktop
- Call read operations: succeed (list_directory, search_files)
- Call write operation (edit_file): intermittently hangs for 4 minutes, then times out with "unresponsive"
- Subsequent calls also hang
Fix that worked:
- Install globally:
npm install -g @modelcontextprotocol/server-filesystem - Update config
commandto the direct binary path, removenpxand-y - Writes now succeed reliably
Hypothesis:
npx -y may be re-resolving/re-downloading the package on each stdio handshake, introducing a race with Claude Desktop's expected startup window. Pinning the binary path skips npx entirely. This would affect every macOS user following the default install docs.
Suggested docs change:
Recommend npm install -g + direct binary path in the Filesystem MCP README as the production-grade install pattern, rather than the npx -y pattern which appears more fragile.
Activity
FazeelUsmani commentedon Apr 27, 2026
Looking into this. One thing I want to check first - reads work fine and only
edit_filehangs, which doesn't really fit the "npx is re-downloading" theory (that would break startup, not specific tools). Going to try to reproduce both ways before assuming it's a launcher issue.Quick question on scope before I dig in - if it turns out the hang is actually in
npx/ Claude Desktop and not in this repo's code, would a README note about using a global install still be wanted? Asking because CONTRIBUTING.md leans away from documenting workarounds.pmabray commentedon Apr 27, 2026
Thx - I think this is erroneously created by the MCP being flagged ask, and doesn't trigger the event. By tuning everything onto allow, the filesystem now works every time.
cliffhall commentedon Oct 19, 2026
Closing: superseded by the v2 release.
Thank you for reporting this, and apologies for the long wait for a response.
Since this was filed, the reference servers have been rebuilt for the 2026-07-28 MCP specification (#4857) and released as v2 (2.0.0 on npm for the TypeScript servers, 2026.10.19 on PyPI for the Python servers). Each server now runs on v2 of its SDK, and the behavior described here has either been fixed or no longer exists in the same form. You traced the hang to the client's ask-permission setting not prompting, and it went away once tools were allowed; no server defect was identified.
This is not a judgment on whether the problem was real; it's a consequence of the code it describes having been replaced. This is happening as part of the backlog triage in #4875.
If this still happens on the v2 release, we'd genuinely like to know. Please open a fresh issue with the version you're running and steps to reproduce, and we'll look at it. Note that this repository accepts contributions as issues rather than pull requests; see
CONTRIBUTING.md.Thanks for taking the time to report it.