Bug Report: server-filesystem tools/call never dispatched by Claude Desktop after initial handshake (Windows)

[MandradeMaking]

`

Description

On Claude Desktop for Windows (v2.1.22 / app 1.1.1520), the @modelcontextprotocol/server-filesystem server completes the full MCP handshake (initialize → tools/list) successfully, but subsequent tools/call messages are never sent by the client to the server. The server stays connected and healthy, but no file operations ever reach it.

This regression was introduced in Claude Desktop CCD v2.1.22. The same setup worked correctly on v2.1.20 and earlier.

---

Environment

Item | Value -- | -- OS | Windows 10 (10.0.26200) Claude Desktop version | app 1.1.1520 / CCD 2.1.22 Node.js | 20.18.1 (system) / 22.21.1 (bundled in Claude Desktop) @modelcontextprotocol/server-filesystem | latest (installed globally via npm install -g) CPU | Intel Core i7-6600U RAM | ~21 GB

---

Configuration (claude_desktop_config.json)

json

{
  "mcpServers": {
    "filesystem": {
      "command": "node",
      "args": [
        "C:\\Users\\mandr\\AppData\\Roaming\\npm\\node_modules\\@modelcontextprotocol\\server-filesystem\\dist\\index.js",
        "C:\\IA"
      ]
    }
  }
}

Note: Using node directly instead of npx was required as a workaround — npx caused the stdio pipe to break entirely on this version of Claude Desktop. The original config used "command": "npx" with "-y" as the first arg.

---

Steps to Reproduce

1. Install @modelcontextprotocol/server-filesystem globally:

   npm install -g @modelcontextprotocol/server-filesystem

2. Configure claude_desktop_config.json pointing command to node and args to the installed index.js + allowed directory.
3. Open Claude Desktop. The server starts and the handshake completes successfully (visible in mcp-server-filesystem.log).
4. Ask Claude to read or list any file/directory in the allowed path.
5. Expected: A tools/call message appears in the log and the server responds with file data.
6. Actual: No tools/call is ever sent. The request hangs indefinitely on the client side. After ~20 minutes the server is disconnected with Server transport closed unexpectedly.

---

Logs

mcp-server-filesystem.log (relevant excerpt)

[filesystem] [info] Server started and connected successfully
[filesystem] [info] Message from client: {"method":"initialize",...,"id":0}
[filesystem] [info] Message from server: {"jsonrpc":"2.0","id":0,"result":{...}}
[filesystem] [info] Message from client: {"method":"notifications/initialized",...}
[filesystem] [info] Message from client: {"method":"tools/list",...,"id":1}
[filesystem] [info] Message from server: {"jsonrpc":"2.0","id":1,"result":{"tools":[...]}}

// ← Nothing after this. No tools/call ever arrives.
// ~20 min later:

[filesystem] [info] Server transport closed
[filesystem] [error] Server disconnected. Server transport closed unexpectedly, this is likely due to the process exiting early.

main.log (relevant excerpt)

[info] Launching MCP Server: filesystem
[info] Checking if UtilityProcess should be used for extension filesystem
[warn] UtilityProcess Check: Extension filesystem not found in installed extensions
// ...
[info] [EventLogging] Sending event: desktop_mcp_unexpected_close | extension_name: 'filesystem'

The warning Extension filesystem not found in installed extensions appears on every startup. This may be related — Claude Desktop may be failing to properly route tools/call messages because it doesn't find the server registered as an extension internally.

mcp.log

Mirrors the same pattern: handshake completes, list_allowed_directories (id:2) is the only tools/call that occasionally goes through (likely due to timing — it fires within the first few seconds of connection). All subsequent calls are never dispatched.

---

Key Observations

1. The server is healthy. Running it manually (node index.js C:\IA) works perfectly — it responds to all commands when called directly.
2. Node.js has no I/O issues with the directory. fs.readdirSync('C:\\IA') works fine from the command line.
3. The first tool call sometimes succeeds. list_allowed_directories went through once, within ~23 seconds of connection. All subsequent calls hang. This suggests a race condition or timeout in Claude Desktop's MCP message routing after the initial handshake.
4. Regression in v2.1.22. The main.log history shows the setup worked on CCD v2.1.20 and prior. The issue started after the automatic update to v2.1.22 on 2026-01-31.
5. npx makes it worse. When using npx as the command (default config), the stdio pipe breaks entirely and even the handshake fails. Using node directly is required but doesn't fully resolve the tools/call dispatch issue.

---

Expected Behavior

After a successful handshake, Claude Desktop should dispatch tools/call messages to the server for any filesystem operations requested by the user. The server should remain connected for the duration of the session.

Actual Behavior

tools/call messages are never dispatched after the handshake. The connection eventually times out and closes with an unexpected disconnect event.

---

Workaround

None that fully resolves the issue. Toggling the filesystem connector off/on in Claude Desktop's Connectors menu forces a reconnect, but the same timeout applies — only calls made within the first few seconds after reconnect have a chance of going through.

---

Additional Notes

• This issue may actually be a Claude Desktop client bug rather than a server bug. The server behaves correctly in all tests. The problem is that the client never sends the tools/call after handshake.
• Consider also filing this against the Claude Desktop / Anthropic side, as the UtilityProcess warning and the desktop_mcp_unexpected_close event suggest the issue is in how Claude Desktop manages MCP server lifecycle on Windows.

`