[BUG] Filesystem extension: `tools/call` never reaches server — repro across multiple models (Fable, Sonnet 5), still present in 1.22209.3

Same here and can confirm on macOS.

Reproducing the exact behavior described: Filesystem extension connects and initializes fine, tools/list returns normally, but any actual tools/call (e.g. list_allowed_directories, read_text_file) fails with the orange "Failed to call tool" notification in the UI. Server-side log shows initialize, notifications/initialized, and tools/list all succeeding, with no tools/call entry ever logged — so the request is being dropped client-side before it reaches the extension process, just as reported.

Platform: Claude Desktop 1.22209.3
OS: macOS
Extension: Filesystem (built-in Node.js)
Config: unchanged for months, previously working, began failing suddenly
Not model-specific — reproduced across models
Updating to the latest build did not resolve it

No config change on my end fixes it, consistent with this being a Desktop client/routing regression rather than an extension problem. Would appreciate a fix. The extension is unusable for any file operation until then.

Same incident cluster: #79926 (Windows ×2, onset ~18:29 UTC 2026-07-21, tools/call never dispatched, survives client update — points at a startup-fetched server-side change) and #79933 (macOS, tools/call DOES reach the server and returns a result, but the web layer's POST /tool_result fails with 404 side_channel_waiting_key_absent). All three: bare "Failed to call tool" in the UI, bundled Filesystem affected, remote connectors and Claude Code CLI unaffected, fresh conversations don't help. Backend request IDs for tracing are in #79933.

Confirming this on macOS as well — same failure pattern exactly.

Environment:

• Platform: Claude Desktop, macOS Sequoia 15.7.7
• Claude Desktop version: Claude 1.24012.1 (0adcae) 2026-07-21T20:59:53.000Z
• Extension: Filesystem (@modelcontextprotocol/server-filesystem), tried both via npx and via a global npm install pointing directly at the binary — same failure either way

Repro:

1. Configured Filesystem MCP server (previously working for a long time, no config changes before failure started).
2. Asked Claude to read a file in an allowed directory.
3. UI returns a generic tool-call failure.
4. Checked mcp-server-filesystem.log and mcp.log — handshake completes cleanly every time, but no tools/call entry ever appears after tools/list.

Log excerpt (mcp.log):

2026-07-22T12:12:02.681Z [info] [filesystem] Server started and connected successfully
2026-07-22T12:12:02.682Z [info] [filesystem] Message from client: method="initialize" id=0 params
2026-07-22T12:12:02.970Z [info] [filesystem] Message from server: id=0 result
2026-07-22T12:12:02.971Z [info] [filesystem] Message from client: method="notifications/initialized"
2026-07-22T12:12:02.989Z [info] [filesystem] Message from client: method="tools/list" id=1 params
2026-07-22T12:12:03.000Z [info] [filesystem] Message from server: id=1 result

No further entries after this, despite multiple subsequent tool-call attempts across several minutes and even a full app reinstall/restart cycle.

Additional data point: confirmed the server binary itself is healthy — running it standalone from Terminal starts cleanly with no errors. This strongly suggests the drop happens in Desktop's client-side tool-dispatch layer before the request ever reaches the extension process, consistent with what's described above for Windows.

This cost me a full day of lost work on a time-sensitive project. Also filed with Anthropic support directly, referencing this issue. Would appreciate any workaround or ETA on a fix.

Found this BR a couple days ago. Experienced the same problem on my M3 MBPro (Mac OS 26.5.2). Just applied today's update to Claude Desktop, v1.24012.9 (build 03c61d), and confirmed this failure mode is now resolved. MCP can access local files again.

Ditto ... joy ensued.