[BUG] Claude Desktop (Windows): Filesystem extension handshake succeeds but tools/call never dispatched — same as closed #22299, reinstall does not fix

Confirming the same regression on Claude Desktop 1.24012.1.0 (same MSIX package Claude_1.24012.1.0_x64__pzs8sxrjxfjjc). A few extra data points that narrow it down further:

Reproduces with the server launched via wsl.exe (Windows → WSL: node inside WSL → @modelcontextprotocol/server-filesystem), so it isn't specific to a Windows-native Node install.
Two independent external stdio servers (two different WSL distros) fail simultaneously and identically — not server-instance-specific.
The built-in "Claude in Chrome" MCP works normally in the same session, so the regression is specific to external stdio MCP servers in Chat mode; built-in MCP is unaffected.
Same signature as reported: mcp.log shows initialize + tools/list succeeding, but no tools/call is ever logged; even list_allowed_directories fails.
Net: healthy initialize/tools/list with a total absence of tools/call points to a client-side dispatch regression for external stdio servers in Chat mode. Claude Code CLI is unaffected (separate config path), consistent with the original report.

Same issue with me

Same issue on the Linux Desktop client.
@modelcontextprotocol/server-filesystem doesn't work either. Failed Toolcalling - but MCP running.

same issue here with me - mcp seems fine but when it actually calls the tools is when i get the errors in the top right corner of Claude Desktop for Windows (Windows 10 for me), my mcpserver using filesystem was working perfectly fine for the past month until hours ago. it just stopped working after i noticed something say "Updating" in the bottom left corner of the Claude Desktop app, and also noticed that it wouldn't even let me type in the prompt momentarily while it was "Updating", and then... it stopped working. Restarting Windows doesn't work.

Can confirm this on Windows, and I have an additional data point that should help narrow it down: the bug is not specific to the extension — it reproduces with a manually configured MCP server too.

Setup

Claude Desktop on Windows, both the Microsoft Store (MSIX) build and the direct-download build. Same behaviour on both.

What I did

After the extension-managed Filesystem server failed as described above, I bypassed the extension system entirely: disabled the Filesystem extension and configured the same server manually via mcpServers in claude_desktop_config.json.

First attempt failed for an unrelated reason worth mentioning: with "command": "npx", Claude Desktop spawns via cmd.exe and the process died immediately with

Der Befehl "C:\Program" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.

i.e. the C:\Program Files\nodejs PATH entry is not quoted when building the command line. Working around that by invoking node directly:

json
"mcpServers": {
"filesystem": {
"command": "C:\\Program Files\\nodejs\\node.exe",
"args": [
"C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npx-cli.js",
"-y",
"@modelcontextprotocol/server-filesystem",
"C:\\path\\to\\folder"
]
}
}

Result

The manually configured server now starts cleanly and stays up — no early exit, no transport error. Handshake completes:

[filesystem] Server started and connected successfully
[filesystem] Message from client: method="initialize" id=0 params
[filesystem] Message from server: id=0 result
[filesystem] Message from client: method="notifications/initialized"
[filesystem] Message from client: method="tools/list" id=1 params
[filesystem] Message from server: id=1 result
[nothing further]

And then zero tools/call entries, across multiple restarts and fresh conversations. Every tool invocation returns "Tool execution failed" instantly. Identical to the extension-managed case.

Why this matters

The manual path shares none of the extension machinery — no extension manifest, no extension MCP config lookup, different process spawn. Both fail the same way. So the No MCP config found for extension ant.dir.ant.anthropic.filesystem warning some of us saw in main.log looks like a symptom rather than the cause, and rolling back or updating the extension won't fix it. The failure appears to sit in the client-side tool dispatch layer, after tools/list succeeds.

Also ruled out on my install

App restart, full PC reboot
Connector toggle off/on, fresh conversations
Extension uninstall/reinstall, full app uninstall/reinstall
MSIX build vs. direct-download build
Server health: launching the same server manually from a shell works fine and responds to tools/call normally

Still reproducing this on:

• Claude Desktop 1.24012.1.0
• OS: Windows
• Node: 24.18.0
• MCP server: @modelcontextprotocol/server-filesystem v2026.7.10

Onset: morning of 2026-07-22 IST UTC+5:30 — same window as this report

Handshake and tools/list succeed every time, but tools/call never reaches the server. Server-side log for a failed list_directory attempt shows nothing past tools/list:

[filesystem] [info] Message from client: method="notifications/initialized"
Client does not support MCP Roots, using allowed directories set from server args: [ 'C:\Users\user-name\source\repos\target-repo' ]
[filesystem] [info] Message from client: method="tools/list" id=1 params
[filesystem] [info] Message from server: id=1 result

No tools/call entry ever appears, even after multiple attempts.

Tried:

• Full restart of Desktop (killed process in Task Manager, not just closed window)
• Fresh/isolated test directory — same failure
• Switching launch command from npx to node with the resolved full path to dist/index.js — no change

Also noticed the exposed tool list itself is inconsistent across the same session — at one point no filesystem tools were listed at all ("Tool not found"), and a later retry exposed a different subset than before (e.g. list_directory_with_sizes present once, then replaced by write_file/read_media_file on a later listing). Might point to instability in tool registration, not just call dispatch.

Other MCP servers connected in the same Desktop instance work fine — only filesystem is affected.

Hi,

I can confirm I am experiencing what appears to be the same issue on Claude Desktop 1.24012.1 (Windows).

I reproduced it with:

• two independent local stdio MCP servers;
• the official @modelcontextprotocol/server-filesystem;
• both npx and a direct node.exe invocation with absolute paths.

In every case:

• initialize succeeds;
• notifications/initialized succeeds;
• tools/list succeeds;
• the server is shown as Connected;
• Claude can list the available MCP tools.

However, every tool invocation immediately returns "Tool execution failed".

The important observation is that no tools/call request is ever sent to the MCP server. The server logs contain only initialize and tools/list; there is never a tools/call message, and the server remains running until Claude Desktop shuts it down normally.

This strongly suggests the failure occurs inside Claude Desktop before the MCP transport dispatches the tools/call request.

Confirming this on my end — same exact pattern.

Environment:

• Claude Desktop for Windows, official Filesystem extension (ant.dir.ant.anthropic.filesystem, v2026.7.10, using built-in Node.js, unsigned per extensions-installations.json)
• App version: 1.24012.1

Log evidence:

mcp-server-Filesystem.log shows the identical signature:
initialize (id=0) → result
notifications/initialized
tools/list (id=1) → result

...then nothing. No tools/call entries at all, despite dozens of tool invocation attempts across multiple days and sessions.

Remediation attempted (same result — no change):

• Toggle connector off/on
• Full app restart (kill process + relaunch)
• Disable/re-enable connector

Additional data point not in the original report:

I isolated the server from Claude Desktop entirely and tested it with MCP Inspector, running the exact same package/version (@modelcontextprotocol/server-filesystem) against the same allowed directory. list_allowed_directories succeeded and returned the correct path. This confirms the server itself is fully functional — the bug is specifically in Claude Desktop's client-side dispatch between a tool invocation in chat and the MCP bridge, not in the server or in directory/permission configuration.

Happy to share full logs (mcp-server-Filesystem.log, mcp.log) if useful.

Update from OP — recovered, with NO local change (same app build, same extension version)

Filesystem tool calls started working again on my machine. The important part: nothing changed locally.

App build: 1.24012.1.0 (unchanged — same MSIX build that was failing)
Extension: ant.dir.ant.anthropic.filesystem v2026.7.10 (unchanged)
No reinstall, no config change, no toggle cycling on my side

Log evidence (mcp-server-Filesystem.log, UTC): server session started 2026-07-22T23:49 with the usual successful handshake. First tool invocation attempt in that same session at 2026-07-23T04:44 — and this time tools/call (id=2) reached the server and returned a result. Ten consecutive tools/call entries (id=2–11) all dispatched and completed normally. The failure signature (handshake OK, zero tools/call entries) is gone.

So the recovery window is between the last confirmed failure (2026-07-22) and 2026-07-23T04:44Z, with identical client and extension binaries on both sides of it. This points to a server-side remote configuration / feature flag change rather than a client patch — which would also explain the sudden onset via silent "Updating" reported by @exdaemon without a version bump.

If you're still hitting this: it may already be fixed for you too — worth retrying list_allowed_directories in a fresh conversation before trying anything else. Would be useful to hear whether recovery is rolling out gradually or hit everyone at once.

Leaving this open until there's an official note on what changed, since the underlying dispatch layer clearly can be broken by a remote-side change without any client update.