Filesystem MCP tool calls silently never dispatched after tools/list — reproduces under both built-in and system Node

### MCP server URL

Filesystem (@modelcontextprotocol/server-filesystem), configured with two allowed directories

### Where does the issue occur?

When pressing the Connect button

### Transport used

streamable-http

### Client registration type

My server does not have auth

### SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

### When did you last reproduce this?

7/22/2026 0930 EST

### Browser and OS

_No response_

### Describe the issue

[mcp-server-Filesystem.log](https://github.com/user-attachments/files/30269626/mcp-server-Filesystem.log)

### Issue details

```shell
Title: Filesystem MCP tool calls silently never dispatched after tools/list — reproduces under both built-in and system Node

Client: Claude Desktop, Windows

MCP Server: Filesystem (@modelcontextprotocol/server-filesystem), configured with two allowed directories

Describe the bug:
Filesystem MCP tool calls stop reaching the server. The server itself is healthy: handshake completes, initialize succeeds, tools/list succeeds and correctly returns both allowed directories. But tools/call requests never appear in the server log afterward — the client never dispatches them. This is not a crash; the process stays alive and connected.

Reproduction steps:

Launch Claude Desktop with the Filesystem MCP server configured.
Open a new chat, ask Claude to call a Filesystem tool (e.g. list_allowed_directories).
Check mcp-server-Filesystem.log: handshake and tools/list succeed, but no tools/call entry ever appears.

Tested variations (same result on all):

"Use Built-in Node.js for MCP" toggle ON
Toggle OFF (forces system Node at C:\Program Files\nodejs\node.exe)
Full quit via Task Manager (killing lingering Claude.exe/node.exe) + relaunch, tested for both toggle states

Additional observation: On at least one occasion in the toggle-OFF state, the log also showed a distinct crash pattern ("Server transport closed unexpectedly... process exiting early" → "Server disconnected"), suggesting a second, separate failure mode layered on top of the primary dispatch issue.

Expected behavior: tools/call requests should dispatch to the server after a successful tools/list, as they did reliably a few days prior to this report.

Log excerpt attached: mcp-server-Filesystem.log showing the pattern across multiple sessions and both toggle states.
```

### Expected behavior

see belowTitle: Filesystem MCP tool calls silently never dispatched after tools/list — reproduces under both built-in and system Node

Client: Claude Desktop, Windows

MCP Server: Filesystem (@modelcontextprotocol/server-filesystem), configured with two allowed directories

Describe the bug:
Filesystem MCP tool calls stop reaching the server. The server itself is healthy: handshake completes, initialize succeeds, tools/list succeeds and correctly returns both allowed directories. But tools/call requests never appear in the server log afterward — the client never dispatches them. This is not a crash; the process stays alive and connected.

Reproduction steps:

Launch Claude Desktop with the Filesystem MCP server configured.
Open a new chat, ask Claude to call a Filesystem tool (e.g. list_allowed_directories).
Check mcp-server-Filesystem.log: handshake and tools/list succeed, but no tools/call entry ever appears.

Tested variations (same result on all):

"Use Built-in Node.js for MCP" toggle ON
Toggle OFF (forces system Node at C:\Program Files\nodejs\node.exe)
Full quit via Task Manager (killing lingering Claude.exe/node.exe) + relaunch, tested for both toggle states

Additional observation: On at least one occasion in the toggle-OFF state, the log also showed a distinct crash pattern ("Server transport closed unexpectedly... process exiting early" → "Server disconnected"), suggesting a second, separate failure mode layered on top of the primary dispatch issue.

Expected behavior: tools/call requests should dispatch to the server after a successful tools/list, as they did reliably a few days prior to this report.

Log excerpt attached: mcp-server-Filesystem.log showing the pattern across multiple sessions and both toggle states.

### Logs from your server

```shell

```

### Additional context

_No response_