[BUG] Claude Desktop MCP: tool call responses dropped by client after first successful round-trip (Windows, regression in CCD v2.1.22)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On Claude Desktop for Windows (CCD 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 Claude Desktop to the server. The server stays connected and healthy, but no file operations ever reach it.

This is a regression introduced in CCD v2.1.22. The exact same setup worked correctly on v2.1.20 and earlier. The main.log history confirms the transition.

The warning UtilityProcess Check: Extension filesystem not found in installed extensions appears in main.log on every startup — Claude Desktop may be failing to route tools/call messages because it doesn't find the server registered as an internal extension.

Related: #14807 (same symptom on Windows)

What Should Happen?

After a successful MCP handshake, Claude Desktop should dispatch tools/call messages to the server for any filesystem operations requested by the user. The server connection should remain active for the full duration of the session and respond to all file read/write/list operations.

Error Messages/Logs

**mcp-server-filesystem.log:**

[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 from the client.
// ~20 minutes 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:**

[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'
  | mcp_cmd: 'node'
  | app_version: '1.1.1520'


**mcp.log:**
The only tools/call that ever went through was list_allowed_directories (id:2), and only because it fired within the first ~23 seconds of connection. All subsequent calls were never dispatched.

---

Steps to Reproduce

1. Install @modelcontextprotocol/server-filesystem globally:

npm install -g @modelcontextprotocol/server-filesystem

1. Edit claude_desktop_config.json (located at %APPDATA%\Claude\claude_desktop_config.json) with this content:

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

Note: Using node directly instead of npx is required — with npx the stdio pipe breaks entirely and even the handshake fails.

1. Open Claude Desktop. Confirm the server starts successfully by checking mcp-server-filesystem.log (located at %APPDATA%\Claude\logs\) — you should see the handshake complete (initialize → tools/list → response).

1. Ask Claude to read or list any file/directory in the allowed path (e.g. "list the files in C:\YOUR_ALLOWED_DIRECTORY").

1. Observe: No tools/call message ever appears in the server log. The request hangs indefinitely on the client side. After ~20 minutes the server is disconnected with "Server transport closed unexpectedly".

Verification that the server itself is healthy:

node C:\Users\YOUR_USER\AppData\Roaming\npm\node_modules\@modelcontextprotocol\server-filesystem\dist\index.js C:\YOUR_ALLOWED_DIRECTORY

Running the server manually works perfectly — it responds to all commands when called directly via MCP inspector or similar tools.

Verification that Node.js has no I/O issues:

node -e "const fs = require('fs'); fs.readdirSync('C:\\YOUR_ALLOWED_DIRECTORY').forEach(f => console.log(f))"

This works fine — the issue is not with Node.js or file system permissions.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

CCD v2.1.20 / app 1.1.1200. The main.log version history confirms: - v2.1.20 (app 1.1.1200) → MCP filesystem worked correctly - v2.1.22 (app 1.1.1520) → MCP filesystem broke - The automatic update to v2.1.22 happened on 2026-01-31 and the issue started immediately after. ---

Claude Code Version

Not applicable — this bug is in Claude Desktop's MCP client implementation, not Claude Code. Claude Desktop version: app 1.1.1520 / CCD 2.1.22.

Platform

Other

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Key observations:

1. The server is completely healthy. Running it manually works perfectly.
2. Node.js has zero I/O issues with the target directory.
3. The first tool call sometimes succeeds if made within ~23 seconds of connection — this points to a race condition or very short timeout in Claude Desktop's MCP message routing after the initial handshake.
4. npx as command makes it completely broken (stdio pipe failure). Using node directly is required but only partially fixes the issue.
5. Toggling the filesystem connector off/on in Claude Desktop's Connectors menu forces a reconnect but the same timeout applies.
6. The warning "Extension filesystem not found in installed extensions" in main.log appears on every startup and is likely the root cause — Claude Desktop may not be properly routing tools/call for servers it doesn't recognize as installed extensions.

Workaround: None that fully resolves the issue. Toggling the connector and making requests within the first few seconds is unreliable and impractical.