[BUG] macOS: Claude Desktop never dispatches tools/call to the first-party Filesystem extension (tools/list succeeds, no tools/call in any log)

Same issue here, adding another macOS data point.

Environment: Claude Desktop 1.24012.1, macOS on an Intel MacBook Pro, Node 24.x via /usr/local/bin, with two local filesystem MCP servers (modelcontextprotocol/server-filesystem).

Symptoms: Both servers complete the MCP handshake on every launch (initialize → tools/list → successful result), but no tools/call request ever reaches either server. The client immediately reports “Failed to call tool.” main.log repeatedly contains:

UtilityProcess Check: Extension <name> not found in installed extensions

The last successful tool_approval_gate entry in my logs was on 2026-07-20, consistent with an auto-update window.

Remediation attempted, all ineffective:

• New conversations inside and outside Projects
• Multiple full app restarts
• Full macOS reboot
• Connector permission reset
• Config regeneration
• Removing and re-adding both connectors
• Replacing npx with a global install and direct absolute-path node invocation, following the workaround discussed in #22299

Control: Claude-in-Chrome tool calls still work, so the failure appears limited to the local MCP tools/call dispatch path rather than the servers themselves or general tool execution.

This blocks all local filesystem workflows. I’m happy to provide sanitized logs or run additional diagnostics. A hotfix or rollback option would be greatly appreciated. Thank you.

Confirming this on three separate Macs, two CPU architectures, and two different Claude accounts, all breaking the same day with no configuration change on any of them.

Environment

3× macOS: 2× Intel, 1× Apple Silicon (macOS versions: 13.7.8 (22H730), 14.8.4 (23J319) and 26.5.2 (25F84))
2 different Claude accounts across those machines
Claude Desktop app - updated at 6:00 am GMT, 22 of July, 2026
First-party Filesystem connector; allowed directory /Users/<user>/Documents/GitHub, unchanged for weeks
Claude Code CLI on the same machines: healthy and unaffected

Identical behaviour on all three. Nothing was changed — the app was simply opened today and the connector was dead.

Same signature as the report

mcp-server-filesystem.log shows a clean handshake on every connection and no tools/call anywhere. Three consecutive connections in one session, zero tools/call across all of them. Excerpt from the last one (taken before I reinstalled the connector; reinstalling changed nothing):

2026-07-22T05:22:34.830Z [Filesystem] [info] Initializing server...
2026-07-22T05:22:34.831Z [Filesystem] [info] Using built-in Node.js for MCP server: Filesystem
2026-07-22T05:22:34.834Z [Filesystem] [info] Server started and connected successfully
2026-07-22T05:22:34.862Z [Filesystem] [info] Shutting down server...
2026-07-22T05:22:34.862Z [Filesystem] [info] Server transport closed (intentional shutdown)
2026-07-22T05:22:34.864Z [Filesystem] [info] Initializing server...
2026-07-22T05:22:34.865Z [Filesystem] [info] Using built-in Node.js for MCP server: Filesystem
2026-07-22T05:22:34.868Z [Filesystem] [info] Server started and connected successfully
2026-07-22T05:22:34.877Z [Filesystem] [info] Message from client: method="initialize" id=0 params
2026-07-22T05:22:35.463Z [Filesystem] [info] Message from server: id=0 result
2026-07-22T05:22:35.464Z [Filesystem] [info] Message from client: method="notifications/initialized"
2026-07-22T05:22:35.502Z [Filesystem] [info] Message from client: method="tools/list" id=1 params
2026-07-22T05:22:35.510Z [Filesystem] [info] Message from server: id=1 result

Failures are instant, not timeouts — consistent with the report and unlike #66726.

Four data points not yet in the thread

Zero-argument control. list_allowed_directories takes no path and touches no file, so it cannot fail a path or permission check. It fails identically to read_text_file, read_multiple_files and get_file_info. All four fail instantly. This rules out the allowed-directory list and macOS file permissions as causes.
Cross-connector control, same session. A remote HTTP connector called from the same chat dispatched and returned a valid result while every Filesystem call failed. Independently reproduces the report's control: the session can execute tools, just not to this extension.
main.log is clean of both known warnings. grep -iE "extension .* not found|shell environment extraction" returns nothing. Neither the #22299 registration warning nor the #43642 shell-environment warning is present, so neither explains this instance.
Rapid teardown/restart churn. In the excerpt above the server is shut down 28 ms after a successful connect, then re-initialised 2 ms later. Unclear whether this is cause or symptom, but it is reproducible in my logs and may be worth correlating against main.log on the app side.

Attempted, did not resolve: full quit and relaunch; remove and re-add the connector; app already on the latest build (auto-updated on a previous restart, so no rollback available).

Why this narrows triage: reproduction across three machines, two CPU architectures and two accounts on the same day eliminates local state, TCC permissions, Node/PATH environment, per-machine config and account-level settings. Whatever changed is common to all installs.

Environment

• Claude Desktop on macOS
• First-party Filesystem extension (ant.dir.ant.anthropic.filesystem), shows as running, Command: node
• One allowed directory (/Users/<user>/Projects/<project>), read-only tools set to Always allow

Symptom
Handshake and tools/list complete normally; tools/call never appears in the Filesystem server log no matter how many calls are attempted. Calls made in a chat session with the connector enabled fail instantly with a generic error, and Claude reports it cannot read files in the allowed directory. Same pattern across multiple app restarts.

mcp-server-Filesystem.log (UTC) — one full clean cycle, then silence:

2026-07-22T06:42:17.178Z [Filesystem] [info] Initializing server...
2026-07-22T06:42:17.181Z [Filesystem] [info] Using built-in Node.js for MCP server: Filesystem
2026-07-22T06:42:17.192Z [Filesystem] [info] Server started and connected successfully
2026-07-22T06:42:17.209Z [Filesystem] [info] Message from client: method="initialize" id=0
2026-07-22T06:42:17.990Z [Filesystem] [info] Message from server: id=0 result
2026-07-22T06:42:18.022Z [Filesystem] [info] Message from client: method="notifications/initialized"
2026-07-22T06:42:18.024Z [Filesystem] [info] Message from client: method="tools/list" id=1
2026-07-22T06:42:18.034Z [Filesystem] [info] Message from server: id=1 result

Nothing follows this despite repeated tool-call attempts afterwards (list_allowed_directories, list_directory, read_text_file — all failed instantly).

I have the same problem on Windows.

System: Windows 11 Home, version 25H2.
Claude Desktop Version 1.24012.1 (0adcae)
Error messages: 'Failed to call tool "read_text_file"' and 'Failed to call tool "list_allowed_directories".
Connector: Filesystem. (built-in / 1st party)

No changes made to permissions.

I'm getting the same as others in mcp-server-Filesystem.log

2026-07-22T07:00:50.120Z [Filesystem] [info] Initializing server... { metadata: undefined }
2026-07-22T07:00:50.126Z [Filesystem] [info] Using built-in Node.js for MCP server: Filesystem { metadata: undefined }
2026-07-22T07:00:50.170Z [Filesystem] [info] Server started and connected successfully { metadata: undefined }
2026-07-22T07:00:50.339Z [Filesystem] [info] Message from client: method="initialize" id=0 params { metadata: undefined }
2026-07-22T07:00:55.100Z [Filesystem] [info] Message from server: id=0 result { metadata: undefined }
2026-07-22T07:00:55.101Z [Filesystem] [info] Message from client: method="notifications/initialized" { metadata: undefined }
2026-07-22T07:00:55.111Z [Filesystem] [info] Message from client: method="tools/list" id=1 params { metadata: undefined }
2026-07-22T07:00:55.116Z [Filesystem] [info] Message from server: id=1 result { metadata: undefined }

Same log messages in mcp.log but without the "{metadata: undefined}". And no [error] level messages logged in these log files or main.log.

in unknown-window.log there are errors logged:

2026-07-22 17:00:51 [error] Setting the document's base URI to 'https://claude.ai/' violates the following Content Security Policy directive: "base-uri 'none'". The action has been blocked.
2026-07-22 17:00:51 [error] Uncaught (in promise) Error: Error invoking remote method '$eipc_message$_935e1991-d508-4ce4-a4ac-d719893bd36a_$_claude.buddy_$_BuddyBleTransport_$_reportState': Error: No handler registered for '$eipc_message$_935e1991-d508-4ce4-a4ac-d719893bd36a_$_claude.buddy_$_BuddyBleTransport_$_reportState'

But those errors were being logged before this issue has come up.

Seeing the identical regression on Windows — and I think I've isolated the root cause, which adds to this report.

Environment: Claude Desktop 1.24012.1 (MSIX / Microsoft Store, Windows 11), using a user-configured MCP server (@modelcontextprotocol/server-filesystem launched via node) in claude_desktop_config.json — i.e. not the first-party Filesystem extension, so this isn't extension-specific.

Same symptom as OP: initialize → notifications/initialized → tools/list all succeed; every tools/call fails instantly with "Tool execution failed"; and there is no tools/call entry in mcp.log or mcp-server-filesystem.log — the call never reaches the server. Survives a full uninstall/reinstall.

Root cause (from main.log): the Desktop MCP client validates the tools/list response with Zod and throws for every tool:

$ZodError: {
  code: "invalid_value",
  values: ["object"],
  path: ["tools", N, "inputSchema", "type"],
  message: "Invalid input: expected \"object\""
}
    at new $ZodError (...\app.asar\.vite\build\index.chunk-*.js)
    at ... vm._onresponse ... _transport.onmessage

The server sends a spec-compliant inputSchema: { "$schema": "...draft-07...", "type": "object", "properties": {...} } (confirmed by dumping the raw tools/list from the server over stdio), so the client is rejecting valid input. That validation failure invalidates the whole tool list, which is exactly why tools/call is never dispatched and nothing appears in the server logs.

Server-agnostic: reproduces identically on @modelcontextprotocol/server-filesystem 2026.7.10 and 0.6.2.
Client-specific: the same servers, same machine, work flawlessly from Claude Code (CLI) — so the fault is in the Desktop MCP client, not the server.

So this appears to be the Windows manifestation of the same 1.24012.1 regression, with the underlying cause being the client's Zod validation of tools[].inputSchema.type rejecting standard schemas. Last-known-good for me matches the version noted here. Happy to attach the full main.log ZodError block, mcp.log, and the server-side log.

Another macOS data point, matching this report and the root cause in the Zod validation comment below.

Environment: Claude Desktop 1.24012.1, macOS 26.5.2 (Build 25F84), 2 separate Macs (both personally owned, unrelated networks).

Symptom: Identical — initialize → tools/list succeed, every tools/call fails instantly with Failed to call tool "<name>". Reproduces on both the first-party Filesystem connector and a user-configured local stdio MCP server (@modelcontextprotocol/server-filesystem), with the exact same error format on both. No tools/call entry ever appears in mcp-server-*.log on either connector.

Isolation done on my end:

• Ruled out network/VPN/Wi-Fi (remote work, home network, tools/list works fine over the same connection)
• Ruled out server health (driving the same server directly via raw JSON-RPC over stdio returns correct results)
• Ruled out custom-config-specific cause (both the built-in Filesystem extension and a custom stdio server fail identically)
• Claude Code CLI on the same machine, same account, same MCP server config: works correctly — consistent with this being a Desktop-client-only regression

Began abruptly on 2026-07-21 with no config changes on my side, same timing as other reports here.

This is currently blocking day-to-day local-file workflows for me. Any update on an ETA for a Desktop patch/rollback would be very welcome — happy to provide sanitized logs if useful.

Same behaviour on Windows, so this is not macOS specific.

Environment: Claude Desktop 1.24012.1, Windows 11 Pro 10.0.26200 (x64), first-party Filesystem extension.

Identical fingerprint. The server starts, then initialize, notifications/initialized and tools/list all complete and return results. No tools/call entry ever appears in the extension log. Every call fails instantly in the UI with "Failed to call tool".

One detail worth adding: list_allowed_directories fails the same way. It takes no arguments and does not read the filesystem, so a path validation or permissions explanation does not fit. The request is not reaching the server at all.

Also tried without success: full quit from the tray and restart, re-saving allowed directories, and a complete package removal (Remove-AppxPackage -AllUsers plus deleting %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc) followed by a fresh install. After reinstall the tools register normally and fail exactly as before.

Earlier entries in the same log show "UtilityProcess spawn timeout after 5000ms" and "Server transport closed unexpectedly", which may or may not be related.

Happy to supply the full log.

Also on Windows 1.24012.1, same fingerprint (tools/list OK, 0× tools/call, fails
instantly). Confirming tyang4-ai's Zod root cause matches what I see, and reinstall
didn't help here either (per Kangooaus).

One data point I haven't seen mentioned: on my machine the user-configured
server-filesystem is spawned twice from a single mcpServers entry — two node PIDs,
both children of the live Desktop process, two "announcing" log lines, despite only
one handshake logged. Not sure if it's a side effect of the failed tools/list
validation retrying, or separate. Can others on 1.24012.1 confirm a double spawn?

Description

After updating Claude Desktop from version 1.22209.3 to 1.24012.1, the Filesystem MCP integration stopped working.

The Filesystem MCP server starts successfully and tools are visible in the UI, but every filesystem tool call fails immediately.

The same configuration worked correctly before the update.

---

Environment

• OS: Windows 10
• Claude Desktop version:
• Working: 1.22209.3
• Broken: 1.24012.1
• Installation type: Microsoft Store (MSIX)
• Filesystem MCP:
• Official Anthropic Filesystem extension
• @modelcontextprotocol/server-filesystem

---

Timeline

Before update:

• Claude Desktop 1.22209.3
• Filesystem MCP worked normally
• Successfully used:
• list_directory
• read_text_file
• edit_file
• write_file

After update:

• Claude Desktop automatically updated to 1.24012.1
• Filesystem MCP tools started failing immediately

---

Steps to reproduce

1. Install Claude Desktop 1.24012.1
2. Enable the official Filesystem extension
3. Configure allowed directory:

C:\Temp

(or any local directory)

1. Open a new conversation
2. Call:

list_allowed_directories

or

list_directory

---

Expected behavior

Filesystem tools should execute and return directory/file information.

---

Actual behavior

Tool call fails immediately:

Failed to call tool "list_allowed_directories"

Failed to call tool "list_directory"

Tool execution failed

---

Debug information

The MCP server itself appears to start correctly.

Logs:

Launching MCP Server: Filesystem

Secure MCP Filesystem Server running on stdio

Client does not support MCP Roots,
using allowed directories set from server args:
['C:\Temp']

The extension UI shows:

• Filesystem: Enabled
• Requirements: All satisfied
• Tools available: 14

However, actual tools/call execution fails.

---

Troubleshooting performed

Tested the following:

Configuration

• Recreated MCP configuration
• Reinstalled official Filesystem extension

Path

Tested:

C:\Users<username>\Documents\Obsidian Vault

and

C:\Temp

Both fail.

Windows user profile

Created a completely new Windows local user account and tested again.

Result:
Same failure.

MCP server

Tested both:

1. Local MCP configuration:

@modelcontextprotocol/server-filesystem

1. Official Anthropic Filesystem extension

Result:
Both fail.

---

Additional observation

The failure started exactly after the Claude Desktop update:

1.22209.3 → 1.24012.1

No configuration changes were made before the failure.

The same machine and configuration worked correctly on 1.22209.3.

---

Logs

Relevant behavior:

• MCP server startup: successful
• tools/list: successful
• tools/call: fails

This looks like a regression in the MCP tool execution path after version 1.24012.1.

Could you please investigate whether there is a regression affecting Filesystem MCP tool calls in this release?

Thank you.

Also on Windows 11, app 1.24012.1 (direct-download installer, not Store version — ruled that out explicitly).

Confirming the same fingerprint: tools/list succeeds, zero tools/call ever dispatched, fails instantly in the UI.

Regarding the double spawn — I don't have a clear confirmation either way from my logs. My logs show clean single-handshake sessions, but I did observe one UtilityProcess spawn timeout after 5000ms during a mid-session restart where the server appeared to initialize twice in quick succession before shutting down. Whether that constitutes a double spawn in the way you're describing, I can't say definitively — my logging may not be granular enough to catch it.

What I can confirm: reinstall made no difference, and the issue onset matches yours — started 2026-07-22 with no config changes on my end.

Same symptom on Windows 11

Environment

• Claude Desktop 1.24012.1.0, MSIX from Microsoft Store (package Claude_1.24012.1.0_x64__pzs8sxrjxfjjc), Electron app
• First-party Filesystem extension (built-in Node.js runtime, 14 tools)
• Tool calls issued from a claude.ai conversation routed to the desktop via the device bridge (wss://bridge.claudeusercontent.com/...)

Timeline

• Last successful tools/call in mcp-server-Filesystem.log: 2026-07-21T09:58:44Z (pre-update version; main.log has rotated so I can't recover the exact previous version number).
• App updated to 1.24012.1.0 on 2026-07-22, before any Filesystem access was attempted that day.
• Since the update: zero tools/call entries in the log across the whole day (verified with grep), while every session shows a clean handshake.

Log evidence (mcp-server-Filesystem.log, representative session after update — identical pattern repeats across 5+ app restarts):

2026-07-22T08:45:31.505Z [Filesystem] [info] Initializing server...
2026-07-22T08:45:31.509Z [Filesystem] [info] Using built-in Node.js for MCP server: Filesystem
2026-07-22T08:45:31.522Z [Filesystem] [info] Server started and connected successfully
2026-07-22T08:45:31.730Z [Filesystem] [info] Message from client: method="initialize" id=0
2026-07-22T08:45:31.868Z [Filesystem] [info] Message from server: id=0 result
2026-07-22T08:45:32.024Z [Filesystem] [info] Message from client: method="notifications/initialized"
2026-07-22T08:45:32.030Z [Filesystem] [info] Message from client: method="tools/list" id=1
2026-07-22T08:45:32.032Z [Filesystem] [info] Message from server: id=1 result
<-- nothing further; no tools/call ever arrives -->

main.log on the app side also looks healthy at the same time:

[LocalMcpServerManager] Connected to Filesystem (14 tools)
[localMcpBridge] announcing Filesystem: 14 tool(s)
[remote-tools-device] connecting wss://bridge.claudeusercontent.com/devices/<org-uuid>_<session-uuid>/<device-id>/bridge
[remote-tools-device] authenticated

Caller side (claude.ai conversation) fails instantly with a generic Tool execution failed — matching the OP's instant failure, not a timeout.

Attempted, did not help

• Full app restart (multiple times)
• Killing all Claude.exe processes via Task Manager, then a single clean start

Possibly related observations on Windows (may or may not be the same root cause)

1. After the update, every line in main.log is written twice (duplicate log transport or duplicate init path?). Before the update, lines were single.
2. Every startup logs: [Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked, copyfile '...\WindowsApps\Claude_1.24012.1.0_x64__pzs8sxrjxfjjc\app\resources\chrome-native-host.exe' -> '...\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe'

Given the OP's report that a full wipe + reinstall did not resolve it on macOS, I have not attempted MSIX Repair/Reset. Happy to provide sanitized full logs if useful.

Also affected on macOS, same build (1.24012.1), same onset date (2026-07-21), same symptom: initialize → notifications/initialized → tools/list all succeed, but tools/call is never emitted — no tools/call entry ever appears in mcp.log, the per-server log, or main.log. The server sits idle and healthy. My server is a manually configured local stdio server (not a first-party extension), so combined with your Directory-installed Filesystem case this confirms the bug is independent of how the server is registered.

Some additional data points from isolating the failure that may help narrow it down — in particular, it does not hit all local servers equally:

• A different local stdio server works fine on the exact same 1.24012.1 install. @wonderwhy-er/desktop-commander (node/npx, stdio) dispatches tools/call normally and gets results, in the same session where my other server never does. So whatever changed, it discriminates between local stdio servers rather than breaking the tools/call path wholesale.

• The same server binary works perfectly through other MCP clients. Driven via Codex CLI and via Claude Code (same machine, same binary, same config target), tools/call is dispatched and answered correctly every time. The server is provably healthy end-to-end; only the Claude Desktop 1.24012.1 surface drops the call.

• Protocol version is not the cause. My server negotiates 2025-11-25 (kotlin-sdk mirrors the client's offered version); Desktop Commander negotiates 2025-03-26. To test whether the newer version triggers the drop, I put a tiny stdio proxy in front of Desktop Commander that rewrites its initialize result's protocolVersion to 2025-11-25. It still dispatched tools/call and returned results normally. So a forced 2025-11-25 on an otherwise-working server does not reproduce the bug — protocol version can be ruled out.

• Tool annotations are not the cause. My failing server originally sent lean annotations (readOnlyHint only, no title/destructiveHint). I aligned them to Desktop Commander's shape (added title to every tool, explicit destructiveHint/openWorldHint on write tools), rebuilt, restarted. No change — still no tools/call.

Remaining observed difference between the working and non-working server (unverified as causal): the working one advertises capabilities: {tools, resources, prompts, logging}, mine advertises only {tools}. Flagging in case the client-side dispatch path branches on advertised capabilities.

Environment: macOS, Claude Desktop 1.24012.1.

mcp-server-filesystem.log
main.log

Reproduced on Windows 11 (MSIX packaged install), app 1.24012.1, same symptom.

Two differences from the original report that may help narrow the cause:

1. Platform: Windows x64, MSIX/packaged install (Node 24.18.0). Logs live

under %LOCALAPPDATA%\Packages\Claude_<pkg>\LocalCache\Roaming\Claude\logs,
not %APPDATA%\Claude\logs.

1. Server type: NOT the first-party Directory extension. This is a manually

configured stdio server in claude_desktop_config.json:

   "filesystem": {
     "command": "npx",
     "args": ["-y", "@modelcontextprotocol/server-filesystem", "<dirs>"]
   }

So the failure covers both the first-party extension (OP) and a hand-configured
npx stdio server (this report), which rules out the "extension not found in
installed extensions" registration theory from #22299 as the sole cause.

Timeline — auto-update, no config change on my side:

2026-07-22 08:10:01 [info] [updater] Update downloaded and ready to install { releaseName: 'Claude 1.24012.1' }
2026-07-22 08:11:58 [info] Starting app { appVersion: '1.24012.1', isPackaged: true, platform: 'win32', arch: 'x64', nodeVersion: '24.18.0' }

Worked normally the previous day. Broke immediately after this update.

Server log — healthy handshake, nothing after tools/list, despite three
tool calls issued from chat (list_allowed_directories x2, list_directory):

09:13:17.108Z [filesystem] [info] Server started and connected successfully
09:13:18.220Z [filesystem] [info] Message from client: method="initialize" id=0 params
09:13:19.562Z [filesystem] [info] Message from server: id=0 result
09:13:19.578Z [filesystem] [info] Message from client: method="notifications/initialized"
09:13:19.585Z [filesystem] [info] Message from client: method="tools/list" id=1 params
09:13:19.589Z [filesystem] [info] Message from server: id=1 result
// nothing further — no tools/call ever reaches the transport

Note that list_allowed_directories takes no parameters and still fails, so
this is not an argument-serialization issue (cf. #4197).

Control: a different MCP server (remote HTTP transport, not stdio) dispatched
and returned results normally in the same session. Only the locally launched
stdio server is affected.

Verified not the cause:

• Server runs fine standalone: npx -y @modelcontextprotocol/server-filesystem U:\Bloob-Below

starts and reports "Secure MCP Filesystem Server running on stdio".

• Full machine reboot: no change.
• All allowed directories are mounted and reachable (cf. #3232).

Last working: 2026-07-21T21:32:49.201Z
Claude Code CLI on the same machine is unaffected.

Confirming on the same build (1.24012.1, macOS 15.7.7), with an additional
data point: this is NOT limited to the first-party Filesystem extension.

A user-configured stdio server in claude_desktop_config.json running the
official @modelcontextprotocol/server-filesystem (2025.11.25) shows the
identical failure: initialize + tools/list succeed (logged in
mcp-server-<name>.log), tools/call is never dispatched — no entry in any
log, no permission dialog, generic "Tool execution failed" in chat.
Renaming the server key, switching between local install and npx@latest,
and fresh chats made no difference.

Control in the same session: two other stdio servers from the same config
(JetBrains PhpStorm MCP, @playwright/mcp) dispatch tools/call normally,
verified via their server logs. So the drop appears specific to
filesystem-type servers, regardless of whether they are the bundled
extension or user-configured.

Reproducing the exact same symptom on Windows, so this is not macOS-specific.

Claude for Windows 1.24012.1 (0adcae) — same build number as the reporter
First-party Filesystem extension from the Directory, ant.dir.ant.anthropic.filesystem v2026.7.10
Handshake completes (initialize → notifications/initialized → tools/list all succeed), then no tools/call ever appears in mcp-server-Filesystem.log or main.log
Every call fails instantly in the UI: Failed to call tool "list_allowed_directories" / "list_directory"
Tried and did not help: removing legacy claude_desktop_config.json entries, reinstalling the extension from the Directory, re-saving allowed directories, full app restart, signing out and back in, testing in brand-new conversations
One extra detail: main.log on Windows reports appVersion: '1.1.7203' while the About dialog shows 1.24012.1 — mentioning in case the internal version string helps narrow the build

Happy to attach logs if useful.

Generated by Claude Chat:

macOS, 1.24012.1, same fingerprint. Three data points that either aren't in the
thread yet or correct something that is.

1. A non-filesystem server on the same install is equally dead — relevant to
@luwar's capabilities lead and against "filesystem-specific".

Alongside @modelcontextprotocol/server-filesystem I run a custom Node stdio
server (bpmn-js-mcp, unrelated codebase, no filesystem tools). Both are
user-configured in claude_desktop_config.json. Both complete the handshake
normally; neither receives a single tools/call. Verified per-server and in
mcp.log — across the whole of 2026-07-22 there is exactly one tools/call
entry in mcp.log, the last one before the break.

My failing bpmn server advertises "capabilities":{"tools":{}} — the same
lean shape @luwar reports for his failing server, versus
{tools, resources, prompts, logging} on his working Desktop Commander. Two
independent failing servers with {tools}-only capabilities is weak evidence,
not proof, but it fits the branch-on-capabilities hypothesis better than
"filesystem-type servers" (@nagelkarle), which my case contradicts directly.

2. Answering @myNickWasStolen's double-spawn question: yes, confirmed — and
it predates the regression, so it is not caused by the failed tools/list
validation.

ps aux shows two complete process trees per configured server, started in the
same second, while mcp.log records only one Initializing server.... So far
identical to your observation.

But the duplication is old. main1.log from 2026-07-11 already shows every
[updater] Update downloaded and ready to install line written twice, weeks
before the break, on a build where all tool calls worked normally. It also
survived my switching from npx -y to a direct absolute-path node invocation
(which collapsed three process layers to two and cut initialize from 1160 ms
to 26 ms, with no effect on dispatch).

This also contradicts @tuharju's reading that the duplicated main.log lines
began with the update — on my install they did not.

3. Both failure modes occur on the same machine and build.

Most reports here describe the instant Failed to call tool / Tool execution
failed, explicitly distinguished from the ~4-minute hang in #66726. I get both.
Filesystem calls failed instantly twice this morning, ~20 seconds after a clean
relaunch. A bpmn call made minutes ago ran the full ~4 minutes and returned
No result received from the Claude Desktop app after waiting 4 minutes. Same
build, same session, no config change between them. Neither call appears in any
log.

I can't explain what selects between the two surfaces, but if one install
produces both, #66726 and this issue may not be separate defects.

Timeline for the record: last dispatched tools/call on my machine was
2026-07-22T06:07:03Z (id=25, ids sequential and unbroken before that). The app
updated 1.22209.0 → 1.24012.0 (downloaded 2026-07-21 20:33 local) → 1.24012.1
(downloaded 2026-07-22 08:08 local). I cannot separate 1.24012.0 from 1.24012.1:
the ~20 minutes running 1.24012.0 contain no call attempts at all.

Re @yoummmmttt's internal version string: on macOS main.log logs
appVersion: '1.24012.1', matching the About dialog, so the 1.1.7203
mismatch doesn't reproduce here — and @Viral-Studios reports 1.24012.1 on
Windows too, so it appears specific to that install rather than to a platform.

same here, macOS 1.24012.1

Same problem on WIndows 11. Worked until build Claude 1.24012.1 (0adcae) 2026-07-21T20:59:53.000Z installed.
Seeing same messages in the MCP log:
2026-07-22T09:48:46.176Z [info] [Filesystem] Initializing server...
2026-07-22T09:48:46.181Z [info] [Filesystem] Using built-in Node.js for MCP server: Filesystem
2026-07-22T09:48:49.574Z [info] [Filesystem] Server started and connected successfully
2026-07-22T09:48:49.626Z [info] [Filesystem] Message from client: method="initialize" id=0 params
2026-07-22T09:48:50.115Z [info] [Filesystem] Message from server: id=0 result
2026-07-22T09:48:50.235Z [info] [Filesystem] Message from client: method="notifications/initialized"
2026-07-22T09:48:50.236Z [info] [Filesystem] Message from client: method="tools/list" id=1 params
2026-07-22T09:48:50.372Z [info] [Filesystem] Message from server: id=1 result

And these in the mcp-server-Filesystem.log:
2026-07-22T09:48:46.175Z [Filesystem] [info] Initializing server... { metadata: undefined }
2026-07-22T09:48:46.181Z [Filesystem] [info] Using built-in Node.js for MCP server: Filesystem { metadata: undefined }
2026-07-22T09:48:49.574Z [Filesystem] [info] Server started and connected successfully { metadata: undefined }
2026-07-22T09:48:49.626Z [Filesystem] [info] Message from client: method="initialize" id=0 params { metadata: undefined }
2026-07-22T09:48:50.115Z [Filesystem] [info] Message from server: id=0 result { metadata: undefined }
2026-07-22T09:48:50.235Z [Filesystem] [info] Message from client: method="notifications/initialized" { metadata: undefined }
2026-07-22T09:48:50.236Z [Filesystem] [info] Message from client: method="tools/list" id=1 params { metadata: undefined }
2026-07-22T09:48:50.372Z [Filesystem] [info] Message from server: id=1 result { metadata: undefined }

Confirming on macOS, Claude 1.24012.1 (0adcae), same onset window.

One data point: I had a manually-configured npx-based @modelcontextprotocol/server-filesystem entry in claude_desktop_config.json failing this way, so I removed it and installed the first-party Directory Filesystem extension instead, on the same machine. Both fail identically — same instant "Failed to call tool," same healthy handshake, no tools/call in either server's log.

Reproduced on Linux (Fedora), and with data points suggesting this is not purely a client-side regression.

Environment: Fedora 44, KDE Plasma, Claude Desktop via the community repackage of the official Linux .deb (aaddrick/claude-desktop-debian). User-configured stdio filesystem server (npx -y @modelcontextprotocol/server-filesystem), not the first-party extension - so the failure is not limited to ant.dir.ant.anthropic.filesystem.

Identical fingerprint: server initializes, answers tools/list in milliseconds, then zero tools/call entries ever appear in the per-server log. Failure in the UI is instant ("Tool execution failed"), no timeout, no diagnostic signal anywhere. Last fully working session: 2026-07-18 on app 1.22209.x (log shows successful tools/call round-trips). First failure: 2026-07-22 morning.

Evidence against a pure client regression:

1. Downgrading the client does NOT fix it. Tested three versions: 1.24012.0, 1.22209.3 (the version that was demonstrably working on the 18th, and your last-working version), and 1.20186.1. All fail identically.
2. A completely fresh ~/.config/Claude (full wipe, re-login, minimal config with a single filesystem server) fails identically.
3. Renaming the server key in claude_desktop_config.json changes nothing.

Discriminating matrix - the failure is per server class, not transport-wide. In the same session, these local stdio servers dispatch tools/call normally:

• uvx mcp-server-fetch - works
• uvx mcp-server-time - works
• npx @bytebase/dbhub (read-only DB access) - works

While these never receive tools/call:

• @modelcontextprotocol/server-filesystem - dead
• Playwright MCP (browser control) - dead

So local stdio dispatch as such is healthy; specifically filesystem and browser-control servers are never dispatched. Same onset date as this report, across macOS official build and Linux repackage, immune to client downgrade and state wipe - which points at a server-side change rolled out around 2026-07-21 rather than the 1.24012.x binary.

An independent same-day report from another Fedora user with the same symptom (filesystem MCP dead, other MCP servers fine): aaddrick/claude-desktop-debian#811.

Reproduced on Windows — same build, same symptom. Not macOS-specific.

Environment:

Windows 11, Claude Desktop app 1.24012.1 (0adcae), MSIX install (C:\Program Files\WindowsApps\Claude_1.24012.1.0_x64__pzs8sxrjxfjjc)
First-party Filesystem extension (ant.dir.ant.anthropic.filesystem), single allowed directory, all tool permissions set to Always Allow

Timeline (from mcp-server-Filesystem.log):

Last successful tools/call dispatch: 2026-07-21 21:27 UTC. Everything worked normally up to that point.
Server restarted at 21:45 the same day. Since then, every startup shows a clean handshake (initialize → notifications/initialized → tools/list, all answered) and not a single tools/call ever arrives, across dozens of attempts over two days.
Every call fails instantly in the UI with a generic "Tool execution failed". No timeout behavior.

main.log shows a fully healthy pipeline with zero errors at dispatch time: server launched via UtilityProcess (built-in Node), [localMcpBridge] announcing Filesystem: 14 tool(s), then [remote-tools-device] connecting DO bridge ... (+14 local-mcp) to wss://bridge.claudeusercontent.com, followed by authenticated. The tools are announced and visible to the model; dispatch back down never happens.

Attempted, did not resolve:

Toggling the extension off/on
Full app restart (quit from tray)
Testing in brand-new conversations
Uninstalling and reinstalling the extension (clean delete/install cycle in main.log, reinstalled as v2026.7.10) — reproduced immediately after a fresh bridge reconnect announcing all 14 tools

Control: remote MCP connectors in the same session dispatch and return results normally, so tool execution itself works — only local extension dispatch is broken.

This matches the OP exactly: regression began 2026-07-21 with no configuration change, healthy server, zero diagnostic trace, no workaround. Happy to attach logs if useful.

Confirming on Windows 11 — same signature, third platform (macOS in the
original report, Linux/Fedora in aaddrick/claude-desktop-debian#811).

Claude Desktop 1.24012.1.0, MSIX package
Claude_1.24012.1.0_x64__pzs8sxrjxfjjc (confirmed via Get-AppxPackage).
Auto-updated 2026-07-22 at 09:51 local. First launch after the update was
09:53, and the filesystem server has not received a single tools/call since.

Server: @modelcontextprotocol/server-filesystem over stdio, two allowed roots.
The handshake is healthy on every one of the 10 launch cycles that day:
Server started and connected successfully -> initialize id=0 -> result ->
notifications/initialized -> tools/list id=1 -> result. Then nothing.

Quantified from a 4-month server log (18,827 lines, 2026-03-22 to 2026-07-22):

• 7,710 successful tools/call across 83 distinct days, 2026-03-22 to 2026-07-21
• last successful call: 2026-07-21 15:53:28 UTC
• 0 on 2026-07-22, across all 10 cycles

The failure is downstream of the permission layer: on a later attempt the call
passed the client-side approval gate (approval granted, logged client-side) and
the server log still shows no tools/call.

A second stdio server declared in the same config file (custom, node, no npx)
keeps working normally: it received tools/call on 2026-07-22 at 08:24:38 and
09:13:14 UTC, both returning result(1 blocks). In the same conversation,
calling that server returns a real application-level error while a filesystem
call returns a generic "Tool execution failed" — so the client can reach local
stdio servers, it just never emits the call for this one.

Ruled out on my side, each verified:

• config syntax and paths (JSON validated, Test-Path OK on both roots)
• launcher: cmd /c npx vs direct node.exe on the global module — identical failure
• server key name: renamed, fresh registration and fresh log — identical failure
• package version: pinned 2026.1.14 with the npx cache cleared — identical

failure to 2026.7.10

• orphan processes: none present with the app fully quit
• per-connector permissions: all set to allow

Side observation, possibly unrelated: claude.exe spawns two instances of every
declared MCP server, one second apart. It affects the working server too.

Full logs available if useful.

Windows confirmation — Windows 11 Pro, Claude Desktop 1.22209.3 (MSIX/Store install), user-configured stdio filesystem server (@modelcontextprotocol/server-filesystem launched via cmd /c npx).

Same signature as reported: on every connection the full handshake succeeds (initialize → notifications/initialized → tools/list), but tools/call never reaches the server. No error is logged anywhere — the failure is silent.

One data point that may narrow the regression window: on Windows this is already broken in 1.22209.3, not only 1.24012.x.

Timeline on this machine:

• Last tools/call that reached the server: 2026-07-21T15:53:28Z (app 1.22209.0, worked reliably for ~4 months, ~7700 tools/call log lines)
• App auto-updated 1.22209.0 → 1.22209.3 on 2026-07-22 09:53 (local)
• Since the update: zero tools/call entries in the MCP server log (%LOCALAPPDATA%\Packages\Claude_*\LocalCache\Roaming\Claude\logs\mcp-server-fs.log), while initialize/tools/list succeed on every reconnect

Client side, the renderer log shows the calls are emitted and pass the approval gate, then vanish before reaching the server. Raw excerpt from logs\claude.ai-web.log (lines 1896–1907; the last two lines are the final entries in the file — nothing follows them):

2026-07-22 13:31:09 [warn] MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 $eipc_message$_935e1991-d508-4ce4-a4ac-d719893bd36a_$_claude.web_$_AutoUpdater_$_updaterState_$store$_update listeners added. Use emitter.setMaxListeners() to increase limit
2026-07-22 13:31:09 [warn] MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 $eipc_message$_935e1991-d508-4ce4-a4ac-d719893bd36a_$_claude.web_$_LocalAgentModeSessions_$_sessionsBridgeStatus_$store$_update listeners added. Use emitter.setMaxListeners() to increase limit
2026-07-22 13:31:49 [warn] [MCP] tool_approval_gate {"toolId":"toolu_0138qMh7wJUDmB5vyoJjLcvK","toolName":"memory_append","approvalRequired":false,"hasBufferedInput":false}
2026-07-22 13:32:32 [warn] [MCP] tool_approval_gate {"toolId":"toolu_01Uq9r5vbQJdtgRrdNTgEnpn","toolName":"fs:list_allowed_directories","approvalRequired":true,"hasBufferedInput":true}
2026-07-22 13:33:17 [warn] [MCP] tool_approval_gate {"toolId":"toolu_014V1FgXnkHg28PdwVcixVmP","toolName":"memory_append","approvalRequired":false,"hasBufferedInput":false}
2026-07-22 13:35:45 [warn] [MCP] tool_approval_gate {"toolId":"toolu_015ALjoB5vEB6624kzq9pPBb","toolName":"memory_append","approvalRequired":false,"hasBufferedInput":false}
2026-07-22 13:37:41 [warn] ProseMirror expects the CSS white-space property to be set, preferably to 'pre-wrap'. It is recommended to load style/prosemirror.css from the prosemirror-view package.
2026-07-22 13:43:49 [warn] Deprecated API for given entry type.
2026-07-22 13:43:51 [warn] MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 $eipc_message$_935e1991-d508-4ce4-a4ac-d719893bd36a_$_claude.web_$_AutoUpdater_$_updaterState_$store$_update listeners added. Use emitter.setMaxListeners() to increase limit
2026-07-22 13:43:51 [warn] MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 $eipc_message$_935e1991-d508-4ce4-a4ac-d719893bd36a_$_claude.web_$_LocalAgentModeSessions_$_sessionsBridgeStatus_$store$_update listeners added. Use emitter.setMaxListeners() to increase limit
2026-07-22 13:44:47 [warn] [MCP] tool_approval_gate {"toolId":"toolu_01SeHYEzfu3DvamFqibXUfzi","toolName":"fs:list_directory","approvalRequired":true,"hasBufferedInput":true}
2026-07-22 13:44:53 [warn] [MCP] tool_approval_gate {"toolId":"toolu_01PLEVfcwE5ADLZfwPodavQo","toolName":"fs:list_allowed_directories","approvalRequired":false,"hasBufferedInput":false}

Call IDs that passed the approval gate but never produced a matching tools/call in the MCP server log:

• toolu_01Uq9r5vbQJdtgRrdNTgEnpn — fs:list_allowed_directories, 13:32:32 (approvalRequired:true)
• toolu_01SeHYEzfu3DvamFqibXUfzi — fs:list_directory, 13:44:47 (approvalRequired:true)
• toolu_01PLEVfcwE5ADLZfwPodavQo — fs:list_allowed_directories, 13:44:53 (approvalRequired:false — approval granted, call still never dispatched)

During the same window the server log only shows healthy initialize/tools/list exchanges ("Server started and connected successfully", tools/list id=1 answered) and no error of any kind.

Same signature on Windows — adding a cross-platform datapoint.

• OS: Windows 11
• Claude Desktop version: 1.24012.1 (0adcae)
• Extension: first-party Filesystem (installed from the Connectors directory)

Symptom identical to OP: tools/list succeeds (tool definitions load into the
conversation normally), but every tools/call fails immediately with a generic
tool-execution error. Reproduced across two separate sessions on the same day,
against multiple tool types (list_allowed_directories, list_directory,
get_file_info, read_text_file).

Attempted, did not resolve:

• Toggling the connector off/on
• Full uninstall → reinstall of the Filesystem extension
• Re-adding the allowed directory after reinstall
• Full app quit (system tray → quit) and restart

Notably list_allowed_directories itself fails, so this reproduces before any
directory-scoped operation. File uploads through the chat UI worked normally
throughout, and the same directory was accessible to other local tooling
(Claude Code) the entire time. Not sharing logs, happy to answer questions.

Same version behaves differently across two Macs — may not be a clean version regression

Reproducing the reported symptom (macOS, first-party Filesystem extension: clean initialize→tools/list handshake, then every tools/call fails instantly with generic "Tool execution failed" — e.g. list_allowed_directories, directory_tree).

I tested across two machines to check the claimed 1.22209.3-good / 1.24012.1-broken boundary from this thread:

| Machine | macOS | Claude version | Result |
|---|---|---|---|
| iMac (2013, Intel) | Sonoma | 1.24012.1 (0adcae), 2026-07-21 | Fails |
| iMac (2013, Intel) | Sonoma | 1.22209.3 (babe11), 2026-07-19 — deliberately downgraded | Fails (identical) |
| MacBook Air M5 (Apple Silicon), not updated | Tahoe | 1.22209.3 (babe11), 2026-07-19 | Works fine |

So the same exact build (1.22209.3) works on one of my Macs and fails on the other. That suggests the 1.22209.3/1.24012.1 boundary reported above may not be a clean, universal version regression — on my setup at least, the iMac fails on both versions tested while the M5 succeeds on the one version tested on it. Points toward something machine/environment-specific — macOS version (Sonoma vs Tahoe), architecture (Intel vs Apple Silicon), TCC/Full Disk Access permission state, or leftover corrupted app state that a plain uninstall/reinstall doesn't clear — compounding with or substituting for whatever the app-level regression is.

For reference, downgrade procedure on the iMac was: quit Desktop → install 1.22209.3 fresh → relaunch → confirm via About. Filesystem connector still failed identically afterward.

Happy to pull mcp.log/main.log from either machine and diff them if that would help narrow this down — let me know what's most useful.

Same issue on Windows. Claude Desktop app updated automatically on 2026-07-22.
Filesystem-style MCP server (@modelcontextprotocol/server-filesystem) does the
full handshake successfully (initialize -> notifications/initialized -> tools/list),
but no tools/call ever reaches the server. Confirmed via mcp.log — tool calls
fail instantly in the UI with "Failed to call tool <name>", server process stays
healthy and idle. Reinstalling/reconfiguring the MCP server in settings did not help.

Cross-referencing: #79992 carries a consolidated evidence ledger for this regression — full local-elimination chain on macOS (app-binary rollback A/B via Time Machine snapshot, extension pack hash comparison, fresh connector identity, cache clear, both approval modes), the duplicate-issue list, and an onset bracket now pinned to ~2026-07-21 15:00Z. The same-version-differs-across-machines observation above fits a staged server-side rollout, which the ledger's timing evidence supports.

<html>
<body>
<!--StartFragment--><p class="font-claude-response-body break-words whitespace-normal" dir="ltr"><strong>Same bug on Windows 11, same build: 1.24012.1.</strong></p>
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr">Started 2026-07-21, no configuration change on my side. Handshake completes, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">tools/list</code> answered, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">tools/call</code> never dispatched, nothing in any log afterward.</p>
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr">My setup differs from OP's in a way that narrows this down: <strong>Windows</strong>, <strong>manually configured stdio servers</strong> in <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">claude_desktop_config.json</code> (no Directory extensions), with Node and Python servers side by side.</p>
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr"><strong>The split is clean and reproducible in the same session:</strong></p>
<div dir="ltr" class="overflow-x-auto w-full px-2 mb-6 print:overflow-x-visible">
Server | Runtime | Result
-- | -- | --
fetch | Python | ✅ works
markitdown | Python | ✅ works
sqlite | Python | ✅ works
filesystem | Node | ❌ no tools/call
memory | Node | ❌ no tools/call
sequential-thinking | Node | ❌ no tools/call

</div>
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr">Three of three Python servers work. Three of three Node servers fail. Same app instance, same restart. Consistent with OP's control observation that a non-Filesystem connector dispatched normally.</p>
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr"><strong>Ruled out by testing:</strong></p>
<ul dir="ltr" class="[li_&amp;]:mb-0 [li_&amp;]:mt-1 [li_&amp;]:gap-1 [&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3 print:block print:space-y-1">
<li class="font-claude-response-body whitespace-normal break-words pl-2"><strong>Launch method</strong> — tried <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">npx -y</code>, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">cmd /c npx</code>, and <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">node.exe</code> directly against <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">dist/index.js</code> with an absolute path. Identical failure.</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2"><strong>SDK version</strong> — tried server-filesystem <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">2026.7.10</code> (SDK ^1.29.0) and <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">2026.1.14</code> (SDK ^1.25.2). Identical failure.</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2"><strong>Extension conflict (#31864)</strong> — does not apply. No duplicate capital/lowercase entries in <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">main.log</code>. The <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Extension X not found in installed extensions</code> warning appears for <strong>all six</strong> servers, including the three Python ones that work, so it is not the discriminator.</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2"><strong>Node health</strong> — Node v24.16.0, npm 11.13.0, single <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">node.exe</code> in PATH.</li>
</ul>
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr"><strong>Manual <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">tools/call</code> succeeds against the same server binary.</strong> Driving the exact server the app launches, with the exact call the app fails to make, returns a valid result on the first try:</p>
<div role="group" aria-label="json code" tabindex="0" class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg focus:outline-none focus-visible:ring-2 focus-visible:ring-accent-100"><div class="sticky opacity-0 group-hover/copy:opacity-100 group-focus-within/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"></div></div><div class="text-text-500 font-small p-3.5 pb-0">json</div><div class="overflow-x-auto"><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed p-3.5" style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code class="language-json" style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre;"><span style="color: rgb(211, 215, 222);">{</span><span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(244, 123, 133);">result</span><span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(211, 215, 222);">:{</span><span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(244, 123, 133);">content</span><span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(211, 215, 222);">:[{</span><span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(244, 123, 133);">type</span><span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(211, 215, 222);">:</span><span style="color: rgb(155, 233, 99);">"text"</span><span style="color: rgb(211, 215, 222);">,</span><span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(244, 123, 133);">text</span><span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(211, 215, 222);">:</span><span style="color: rgb(155, 233, 99);">"Allowed directories:</span><span style="color: rgb(94, 237, 237);">\n</span><span style="color: rgb(155, 233, 99);">C:</span><span style="color: rgb(94, 237, 237);">\\</span><span style="color: rgb(155, 233, 99);">Users</span><span style="color: rgb(94, 237, 237);">\\</span><span style="color: rgb(155, 233, 99);">newju</span><span style="color: rgb(94, 237, 237);">\\</span><span style="color: rgb(155, 233, 99);">jc_vault"</span><span style="color: rgb(211, 215, 222);">}]},</span><span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(244, 123, 133);">jsonrpc</span><span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(211, 215, 222);">:</span><span style="color: rgb(155, 233, 99);">"2.0"</span><span style="color: rgb(211, 215, 222);">,</span><span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(244, 123, 133);">id</span><span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(211, 215, 222);">:</span><span style="color: rgb(94, 237, 237);">1</span><span style="color: rgb(211, 215, 222);">}</span></code></pre></div></div>
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr">The server answers correctly. Claude Desktop simply never sends the request.</p>
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr"><strong>Possibly relevant:</strong> the Node server reports <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">"serverInfo":{"version":"0.2.0"}</code> in the initialize response even though <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">package.json</code> says <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">2026.1.14</code>. Unsure whether Desktop uses <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">serverInfo.version</code> in routing, but the mismatch is real.</p>
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr"><strong>Environment:</strong> Windows 11, Claude Desktop 1.24012.1 (MSIX / Windows Store install, no rollback path), Node v24.16.0, npm 11.13.0, Anaconda Python 3.12.</p>
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr">Happy to provide full logs.</p><!--EndFragment-->
</body>
</html>

Data point from Cowork mode (Claude Desktop) — filesystem access not reproducing here, which may help narrow the scope.

Environment: Claude Desktop, Cowork mode, Claude Sonnet 5, macOS, tested 2026-07-22.

What we tested: Read and write operations against both a temporary working folder and a user-selected/mounted project folder (a Dropbox-synced directory), issued directly from a chat session.

Result: Both succeeded cleanly.

• Wrote a file to the session's own scratch/outputs directory, read it back — OK.
• Wrote a file into the user-mounted project folder, listed the folder contents, read the file back — OK.

Why this might be relevant: Cowork mode's file tools don't appear to route through the same MCP surface as the first-party "Filesystem" connector this issue describes — they use Cowork's own bash/mount-based file access rather than a tools/call round-trip to a standalone Filesystem MCP server process. So this isn't a contradiction of the bug report; it's a potential boundary marker for where the regression does and doesn't reach. If it's useful triage signal: whatever broke tools/call dispatch to the standalone Filesystem MCP server does not appear to affect Cowork's separate file-access path on the same build/date.

Happy to run additional specific checks against this session if it would help isolate the failing path.

Windows 11 datapoint — deep app reset does NOT resolve it, matching the
OP's full macOS wipe.

Claude Desktop 1.24012.1.0, MSIX (confirmed via Get-AppxPackage). Auto-updated
2026-07-22 09:51 local; the filesystem server has received no tools/call since.
Server: @modelcontextprotocol/server-filesystem over stdio, two allowed roots.

Windows equivalent of the OP's wipe: Settings > Apps > Claude > Advanced
options > Reset (clears LocalCache/LocalState), then config restored from
backup, relaunch. Handshake healthy, still zero tools/call.

Also ruled out here: renaming the server key (fresh registration and fresh
log file), and pinning the package to 2026.1.14 with the npx cache cleared
(identical failure to 2026.7.10).

The failure is downstream of the permission layer: a call passed the
client-side approval gate (approval granted, logged client-side) and the
server log still shows no tools/call.

Quantified from a 4-month server log (18,827 lines): 7,710 successful
tools/call across 83 distinct days, 2026-03-22 to 2026-07-21. Last successful
call 2026-07-21 15:53:28 UTC. Zero on 2026-07-22 across 10 launch cycles.

Partial workaround: the same filesystem tools DO execute from a Cowork/desktop
session that has the native device bridge — but mcp-server-fs.log still shows
zero tools/call, so those calls are not going through the broken stdio dispatch
path. In a plain Chat conversation the tools still fail. A second stdio server
declared in the same config file (custom, node, no npx) works normally
throughout.

Confirming the same bug on Windows, with a config-based MCP server (not the Directory extension).

Environment:

Claude Desktop for Windows 1.24012.1 (0adcae)
Windows 10/11, Node.js in C:\Program Files\nodejs
Filesystem server: @modelcontextprotocol/server-filesystem (latest, installed globally via npm), configured in claude_desktop_config.json and launched directly via node.exe (no cmd/npx wrapper), single allowed directory F:\

Symptom (identical to OP):

Server lifecycle is fully healthy in mcp-server-filesystem.log: spawn via node.exe, initialize answered in ~0.5s, tools/list answered in milliseconds, "Secure MCP Filesystem Server running on stdio", allowed directories loaded.
Any tool call (list_directory, list_allowed_directories) fails instantly with the generic UI toast: Failed to call tool "list_directory".
No tools/call ever appears in mcp.log or the server log. The renderer log (claude.ai-web.log) shows the call passing the approval gate — e.g. [MCP] tool_approval_gate {"toolName":"filesystem:list_directory","approvalRequired":false,"hasBufferedInput":false} — and then nothing. No error is logged anywhere in main.log, mcp.log, or the window logs.

Additional data points that may help isolate it:

A second MCP server in the same config works perfectly in the same chat session — Oracle SQLcl (sql.exe -mcp). Its tool calls succeed. Notably, SQLcl negotiates down to protocol 2024-11-05 after the client requests 2025-11-25, whereas the filesystem server accepts the newer protocol. The working server is on the old protocol; the failing one is on the new protocol.
Downgrading the filesystem server to @modelcontextprotocol/server-filesystem@2025.1.14 changes the failure mode: the tools stop registering entirely (model reports no filesystem tools available in new chats).
Reproduced across multiple fresh conversations and full app restarts (including killing all node/cmd processes). The server binary runs fine standalone from PowerShell.
Failure is instant, not a timeout, matching OP's observation #2.

Happy to provide full logs.

Confirming on macOS with a manually-configured stdio filesystem server, not the first-party Directory connector, which suggests the break is in Desktop's tools/call dispatch layer generally rather than the Directory extension specifically.

Build: Claude 1.24012.1 (0adcae), 2026-07-21T20:59:53Z
Server: @modelcontextprotocol/server-filesystem over stdio, two allowed dirs set via server args
Last known good: pre-2026-07-21 (auto-updated to 1.24012.1 yesterday)

Log shows the handshake completing and tools/list answered, then nothing. Firing multiple tool calls from the UI produced "Tool execution failed" instantly each time, with zero tools/call entries reaching the server:

2026-07-22T12:24:28.586Z [obsidian-vault] [info] Message from client: method="tools/list" id=1
2026-07-22T12:24:28.606Z [obsidian-vault] [info] Message from server: id=1 result
(no tools/call ever appears, across repeated invocations)

Discriminators confirmed:

• Server healthy: starts, loads both allowed dirs, answers tools/list in ~20ms
• Network healthy: curl to api.anthropic.com returns 405 (reachable)
• Claude Code CLI on the same machine reads the same directory fine via local file tools
• Failure is instant, not a timeout

So: server, config, and network all healthy; the client never dispatches tools/call. Same signature as the original report, on a non-Directory server.

Reproducing on 1.24012.1 (macOS) with an independent variable that may
help scope this: I hit the identical symptom using a manually
configured stdio server in claude_desktop_config.json, not the
Directory-installed extension.

• command: /opt/homebrew/bin/npx -y @modelcontextprotocol/server-filesystem <dirs>
• Handshake completes, tools/list answered, server healthy and idle.
• Every tools/call fails instantly with "Failed to call tool"; no

tools/call line ever reaches mcp-server-filesystem.log.

So the dispatch failure is not specific to first-party Directory
extensions or to built-in Node — a hand-configured stdio server
launched via Homebrew npx fails identically. Same 1.24012.1 build,
same instant-failure-with-no-transport-activity signature.

Output Log: tail -n 5 ~/Library/Logs/Claude/mcp-server-filesystem.log

2026-07-22T12:56:31.001Z [filesystem] [info] Message from server: id=0 result { metadata: undefined }
2026-07-22T12:56:31.015Z [filesystem] [info] Message from client: method="notifications/initialized" { metadata: undefined }
2026-07-22T12:56:31.016Z [filesystem] [info] Message from client: method="tools/list" id=1 params { metadata: undefined }
Client does not support MCP Roots, using allowed directories set from server args: [ '/Users/username/Documents' ]
2026-07-22T12:56:31.023Z [filesystem] [info] Message from server: id=1 result { metadata: undefined }

Confirming this on my end — reproducible on two separate Macs, same symptoms.

Environment:

• Claude Desktop for macOS, version 1.24012.1 (Oadcae)
• Two separate machines, both macOS, both exhibiting identical behavior
• Filesystem connector pointed at a folder under ~/Library/CloudStorage/GoogleDrive-.../My Drive/... (Google Drive for Desktop, actively syncing, confirmed working/accessible in Finder)

Symptom:

• Every tools/call to the Filesystem connector fails silently — including list_allowed_directories, which takes no arguments and should be the simplest possible health check.
• tools/list on initialization succeeds every time and returns the full tool schema correctly.
• No error, exception, or trace appears in mcp-server-Filesystem.log for any of the failed calls — the log shows a clean initialize → tools/list → server idle, with zero record of the tools/call messages ever arriving, across many session start/stop cycles over several weeks.

Steps tried (none resolved it):

1. Confirmed the allowed directory path is correct and unchanged (copy-pasted, verified byte-for-byte)
2. Clicked Save on the Filesystem connector settings pane with no changes
3. Toggled Enabled off → on → Save
4. Full quit (Cmd+Q) and relaunch of Claude Desktop
5. Started a brand-new conversation thread (ruling out a stale per-conversation session) — identical failure
6. Confirmed the identical failure independently on a second Mac with the same Claude Desktop version

Additional evidence: A non-Filesystem connector (Control Chrome) was not tested for comparison in my case, but the complete absence of any tools/call line in the Filesystem server log — despite dozens of attempts across multiple days — strongly matches the "app's own health probe fails" pattern described above, rather than anything specific to how the model is invoking the tool.

Happy to provide the newer portion of mcp-server-Filesystem.log excerpt if useful for debugging.

You probably don't need it, but same issue on Fedora 43, like @WimCos. Noticed it as of around 11 or so hours ago.

Also affected on Windows — same fingerprint as this issue

Confirming this on Claude Desktop 1.24012.1, Windows (WSL2/Ubuntu-24.04 target dirs, but also reproduces with a plain Windows path like E:\...).

Same symptom as reported: after a clean handshake, tools/call is never dispatched to the Filesystem extension.

From my mcp-server-Filesystem.log, every session cycle looks identical:

Initializing server...
Server started and connected successfully
client: initialize → server: result
client: notifications/initialized
client: tools/list id=1 → server: result
Shutting down server...

The server starts, the handshake succeeds, and tools/list is answered in a few ms — but no tools/call ever reaches the server, for any tool. On the client side the call fails instantly with a generic "failed to call tool"; on the server side there is simply no corresponding log line. Not a timeout — the call never arrives.

Additional data points:

Reproduces with list_allowed_directories (no path argument), so it is not path- or WSL-specific.
Persists after: full app restart (incl. tray quit), toggling the connector off/on, removing and re-adding the Filesystem connector, and a rollback to 1.22209.3 — the same no-dispatch pattern appears on the older version too.
Claude Code CLI on the same machine is unaffected.

+1, same regression on Windows 11 (MSIX install)

Confirms this is cross-platform, not macOS/Linux-specific.

Versions: Last working on 1.22209.3 (confirmed via main.log — filesystem tools/call succeeding through 2026-07-20 evening). Broke on 1.24012.1, which the app auto-updated to on restart.

Symptom: filesystem MCP server completes the full handshake (initialize → notifications/initialized → tools/list) successfully every time, but tools/call is never dispatched to the server. UI shows "Failed to call tool list_directory" / "Failed to call tool list_allowed_directories" instantly, no timeout. No tools/call entry appears in mcp.log or mcp-server-filesystem.log after the update — the server just sits idle and healthy.

Ruled out on my end before concluding this is app-side:

• Config file syntax (rebuilt and JSON-validated from scratch)
• Wrong config file path (confirmed correct MSIX LocalCache path: ...\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\)
• Target folder existing/reachable (confirmed, opens fine in Explorer)
• Stale/orphaned server process (ruled out — persists after a full OS restart, not just app restart)
• Duplicate/conflicting filesystem connector (checked Settings → Connectors — only one filesystem entry, type "Local dev")
• Tool permissions (checked Settings → Connectors → filesystem → Tool permissions — List Directory, Read File, Read Text File all set to auto-allow; a permissions block would surface as a prompt, not an instant silent failure)

Config, folder, permissions, and server are all healthy; only the client's tools/call dispatch is broken. Happy to attach log excerpts if useful.

Confirming this also affects Windows, not just macOS.

Environment:

• Claude Desktop for Windows, updated 1.22209.x -> 1.24 (same regression window)
• filesystem server via @modelcontextprotocol/server-filesystem, launched with node.exe (manually configured in claude_desktop_config.json, not the first-party Directory extension)

Symptoms — identical to this report:

• Full handshake succeeds (initialize, tools/list), server reports healthy and reconnects cleanly every few minutes
• Every tools/call fails instantly in the UI with "Failed to call tool [name]"
• Zero tools/call entries ever appear in the filesystem server log, no matter how many attempts
• No permission dialog appears at any point

Troubleshooting already attempted (no effect on any of these):

• Verified/corrected config paths and JSON syntax
• Updated the @modelcontextprotocol/server-filesystem npm package to latest
• Updated npm itself
• Full OS restart
• Full Claude Desktop update (1.22209.x -> 1.24)
• Full uninstall + reinstall of Claude Desktop
• Isolating filesystem as the only configured MCP server (removed all others)

Control test: a second, manually-configured local MCP server (dart mcp-server, stdio-based, same config file) dispatches and executes tool calls correctly in the same session — so this isn't a general local-MCP dispatch failure, it's specific to the filesystem server/extension.

This matches the "not repairable from the user side" conclusion in the original report — happy to share full logs if useful for debugging.

Reproduces on Windows too — same signature: handshake and tools/list succeed, tools/call never dispatches to the server.

Environment

• OS: Windows 11
• Claude Desktop: 1.22209.3 (also reproduced on 1.24012.0, both Store/MSIX and direct-download .exe installs — packaging and version are not the variable)
• MCP server: custom mcpServers entry (kevin-fs) running @modelcontextprotocol/server-filesystem v2026.7.10 via system Node.js v24.18.0 (C:\Program Files\nodejs\node.exe), not Claude's built-in Node
• Config location: %APPDATA%\Claude\claude_desktop_config.json

What I ruled out first
Before concluding this was app-side, I eliminated every local variable I could think of:

• Installed real Node.js and pointed the server at system node instead of Claude's built-in Node (built-in Node was crashing the extension separately — different issue, but wanted to rule it out)
• Renamed the server entry to something other than filesystem, since Claude Desktop silently ignores/overrides an entry literally named filesystem
• Set isUsingBuiltInNodeForMcp: false
• Uninstalled and reinstalled Claude Desktop clean (Store version → direct claude.com/download version)
• Rolled back through several versions via winget (1.24012.0 → 1.22209.3) — same failure on all
• Removed the duplicate first-party Filesystem extension so only my custom server was registered (early logs showed both launching and colliding — once removed, still fails)

None of it changed the outcome.

Direct proof the server is healthy
Piping the same MCP protocol messages straight to the server via PowerShell (bypassing Claude Desktop entirely) works perfectly:

$body = @'
{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}
{"jsonrpc":"2.0","method":"notifications/initialized"}
{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_allowed_directories","arguments":{}}}
'@
$body | node "C:\Users\Kevin\AppData\Roaming\npm\node_modules\@modelcontextprotocol\server-filesystem\dist\index.js" "C:\Users\Kevin\Desktop\Claude Share"

Result — a correct, complete response:

{"result":{"content":[{"type":"text","text":"Allowed directories:\nC:\\Users\\Kevin\\Desktop\\Claude Share"}], ...},"jsonrpc":"2.0","id":1}

So the server correctly executes tools/call when spoken to directly. The break is specifically in Claude Desktop's dispatch path.

mcp.log from Claude Desktop — repeated across multiple independent sessions

[kevin-fs] [info] Initializing server...
[kevin-fs] [info] Using MCP server command: C:\Program Files\nodejs\node.exe with path: {...}
[kevin-fs] [info] Server started and connected successfully
[kevin-fs] [info] Message from client: method="initialize" id=0 params
Secure MCP Filesystem Server running on stdio
[kevin-fs] [info] Message from server: id=0 result
[kevin-fs] [info] Message from client: method="notifications/initialized"
Client does not support MCP Roots, using allowed directories set from server args: [ 'C:\\Users\\Kevin\\Desktop\\Claude Share' ]
[kevin-fs] [info] Message from client: method="tools/list" id=1 params
[kevin-fs] [info] Message from server: id=1 result

No tools/call line ever appears after this point, in any session, even minutes into a stable connection with no reconnects. This has now been reproduced across four separate Claude Desktop installs/versions (1.24012.0 Store, 1.24012.0 direct, 1.22209.3 direct) with identical results each time.

One additional wrinkle worth flagging for anyone else hitting this: I initially had both the first-party Filesystem extension (using Claude's built-in Node, which crashes separately/silently a few seconds after initialize on Windows) and a custom kevin-fs entry registered simultaneously. Early logs showed the two servers launching and tearing down in rapid succession, which looked like it might be the cause. Removing the built-in extension stopped the churn, but did not fix the underlying issue — tools/call still never dispatches to the remaining healthy kevin-fs server.

Windows confirmation — same regression on 1.24012.1 (MSIX / Microsoft Store)

Confirming this is not macOS-only. Identical symptom on Windows, same app version.

Environment

| | |
|---|---|
| OS | Windows 11 Enterprise 10.0.26100 |
| Claude Desktop | 1.24012.1 |
| Install type | MSIX / Microsoft Store (C:\Program Files\WindowsApps\Claude_1.24012.1) |
| Extension | first-party Filesystem (ant.dir.ant.anthropic.filesystem) |

Notably the install type differs from the reporter's (Store/MSIX vs macOS bundle), so the
regression is not tied to a particular packaging or install path.

Same signature: handshake succeeds, tools/call never dispatched

mcp-server-Filesystem.log — every session since the regression ends at tools/list:

2026-07-22T13:37:33.820Z [Filesystem] Initializing server...
2026-07-22T13:37:34.370Z [Filesystem] Server started and connected successfully
2026-07-22T13:37:36.752Z [Filesystem] Message from client: method="initialize" id=0
2026-07-22T13:37:38.953Z [Filesystem] Message from server: id=0 result
2026-07-22T13:37:39.080Z [Filesystem] Message from client: method="notifications/initialized"
2026-07-22T13:37:39.107Z [Filesystem] Message from client: method="tools/list" id=1
2026-07-22T13:37:39.122Z [Filesystem] Message from server: id=1 result
<- nothing further. No tools/call, no error.

main.log shows the bridge announcing normally, with no error afterwards:

2026-07-22 15:37:39 [info] [localMcpBridge] announcing Filesystem: 14 tool(s)

Last successful tools/call on this machine: 2026-07-22T11:10:42Z. After that point,
across many app restarts and several fresh conversations, the count of tools/call reaching
the server is exactly zero — while tools/list continues to succeed every single time.

Additional data point not in the original report

On Windows the model does not merely fail to dispatch — it reports the connector as absent
from the conversation entirely. Asked directly to call list_allowed_directories in a normal
Desktop chat (connector present, Enabled, directories filled in, all tool permissions set to
Always allow), the reply was:

"Ik kan de Filesystem-connector niet aanroepen — die is in deze omgeving niet beschikbaar. Je zit dus waarschijnlijk in de browser of op je iPhone, niet op de laptop." ("I can't call the Filesystem connector — it isn't available in this environment. So you're probably in the browser or on your iPhone, not on the laptop.")

The model inferred a non-desktop surface, which it would only do if the tools were missing from
its tool set. This suggests the failure is upstream of dispatch: the tools are announced
locally by localMcpBridge but never attached to the conversation sent to the model. That
would explain the total absence of diagnostic signal on both sides — there is no failed
dispatch to log, because no dispatch is ever attempted.

Possibly unrelated observation: MCP Roots override

Since 2026-07-14 the bundled server logs roots-protocol activity that is absent from all
earlier logs (0 occurrences before that date):

15:37:39 Client does not support MCP Roots, using allowed directories set from server args:
         [ 'C:\Users\<user>\Documents\ClaudeCoWork' ]
16:08:09 No valid root directories provided by client
16:08:33 Updated allowed directories from MCP roots: 1 valid directories

Different clients take different branches: plain Desktop chats do not support roots and fall
back to the configured directories, while SDK-backed sessions supply roots that replace the
Allowed Directories set in the Connectors UI — and when no valid root is supplied the list is
empty. Flagging it because it makes the Connectors UI misleading (the configured value is
silently ignored in those sessions), though it appears to predate and be distinct from the
tools/call regression, which began here on 2026-07-22.

Attempted fixes — same list, same outcome

Extension disable → uninstall → machine reboot → reinstall → re-add allowed directory →
restart; all tool permissions set to Always allow; multiple fresh conversations. No change.
Consistent with the original reporter's full-wipe attempt.

Rollback is not available on this install: MSIX/Store apps in C:\Program Files\WindowsApps
cannot be downgraded, and the distributed installer stub always fetches the current version.

Confirming a second independent macOS instance of this, with a different usage profile and config shape.

Environment

• Claude Desktop for macOS, app Claude 1.24012.1 (0adcae) 2026-07-21T20:59:53.000Z
• First-party Filesystem connector, extension v2026.7.10 (self-updated from a prior version at 2026-07-22 02:18, without user action)
• allowed_directories is a single broad path (the user home dir), not narrow project paths

Timeline

• Last successful tools/call: 2026-07-18 14:19. ~1,120 successful tool calls earlier in July, so this is a heavily exercised connector rather than a first-run or edge config.
• App auto-updated 1.22209.0 → 1.22209.3 on 2026-07-20 13:04.
• Extension self-reinstalled v2026.7.10 on 2026-07-22 02:18.
• Caveat on attribution: nothing exercised the connector between the last good call and the first failure, so I cannot pin the break to a specific build from my own logs. The gap is consistent with the 1.24012.1 window reported above.

Matches the original report exactly

• initialize → notifications/initialized → tools/list complete cleanly on every launch; [LocalMcpServerManager] Connected to Filesystem (14 tools) and [localMcpBridge] announcing Filesystem: 14 tool(s) both present.
• Zero tools/call entries in the server log, ever, despite repeated attempts.
• Failure is instant, not a timeout. No exception, rejection, or dispatch attempt logged on the app side.
• Tools are visibly present and invocable in-chat — the model receives the definitions and issues the calls; they die before reaching the transport.

Additional data points

• Broad vs. narrow allowed_directories makes no difference, which rules out a path-scoping cause.
• Org blocklist is empty; no TCC / EPERM / permission-denied entries anywhere in the logs, so macOS privacy permissions are not involved.
• The extension reached v2026.7.10 by self-update rather than manual reinstall, and fails identically — same result, different path to that version.
• Connector toggle off/on produces a clean re-init in the log each time and does not restore dispatch.

Same bug, second machine.

macOS, first-party Directory-installed Filesystem extension, Claude for Mac 1.24012.1 (0adcae). Identical symptom to OP: server starts, loads allowed directories, answers tools/list in milliseconds; every tools/call fails instantly with a "Failed to call tool" toast, no timeout, and zero tools/call entries ever reaching the per-server log. Full quit (verified no surviving processes), relaunch, new conversations, and removing/re-toggling the connector do not resolve.

Additional data from my logs that may help isolate it:

1. Version bisection points at 1.24012.0, not .1. Healthy on 1.22209.x through 2026-07-20. The updater downloaded 1.24012.0 on 07-21 13:07 PT and 1.24012.1 at 15:51 PT (auto-applied on restart). The last successful Filesystem tools/call in mcp.log is 07-21 21:39 UTC (14:39 PT) — before my first restart onto a 1.24012.x build. The first failure signature appears 07-21 15:32 PT, so the regression began with 1.24012.0 and persists in .1.

1. Quantified failure signature in main.log. The [remote-tools-device] connecting DO bridge line reports a local tool count that sits at a stable +61 local-mcp for the entire preceding week. At each breakage moment it re-registers at +47 local-mcp — exactly 14 fewer, the Filesystem extension's tool count — then re-registers at +61 seconds later. After that flap cycle, tools/list still succeeds but no tools/call is ever dispatched. Today's sequence: 08:03 PT healthy registration (+61) → 08:05 drop to +47 → 08:06 re-registration (+61) → all subsequent calls fail instantly.

1. Possibly related — new spawn behavior unique to this build. main.log records Failed to spawn python (via disclaimer): /Applications/Claude.app/Contents/Helpers/disclaimer exited with code 127: Failed to spawn process: No such file or directory in the same minute as the registration flap (08:05:37). The Helpers/disclaimer binary is present and codesign -v --deep on the app bundle passes clean, so this is the spawn broker running and failing to find a bare python — which doesn't exist on stock macOS. This spawn attempt appears exactly once in a main.log spanning 2026-07-14 to present: only in the 1.24012.x era, and only at the moment the tool registry flaps. Prior builds never attempted it. Correlated to the second, not proven causal.

Same signature on macOS (Darwin 27.0.0), Desktop 1.24012.1, first-party Filesystem extension 2026.7.10. Two data points that may help narrow it:

1. The failing call does leave a client-side trace. Each failed call logs a tool_approval_gate line in ~/Library/Logs/Claude/claude.ai-web.log:

2026-07-21 22:12:05 [warn] [MCP] tool_approval_gate {"toolName":"Filesystem:list_allowed_directories","approvalRequired":false,...}

but no corresponding tools/call ever appears in mcp.log or mcp-server-Filesystem.log. The server completes initialize → notifications/initialized → tools/list in every session. So the call is accepted by the chat surface and dropped somewhere between the approval gate and the MCP client transport, silently.

2. Exact regression boundary from main.log. Last successful tools/call: 2026-07-21 19:07:07Z. App auto-updated that evening (beforeQuitForUpdate 22:09:14 local; Version changed since last launch: 1.24012.0 → 1.24012.1 at 22:09:23). First failure: 22:12:05, in the first post-update session. No configuration changes in between. Caveat: 1.24012.0 had been installed earlier that day but no Filesystem call was made while it was running, so I can only bracket the regression to 1.22209.3 → 1.24012.x, consistent with the OP.

Also reproduced the OP's negative results: extension remove/re-add (2026.7.4 → 2026.7.10), app restart, cold boot, fresh conversation — no change. list_allowed_directories (touches no disk) fails identically, which rules out TCC/Full Disk Access as the cause.

Confirmed this issue on Claude Desktop 1.24012.1 (0adcae) on macOS. The first-party Filesystem connector remains enabled with directories configured and saved. The tools/list command succeeds, but subsequent tool calls fail instantly with "Failed to call tool," and no entries appear in mcp.log after tools/list.
The connector appears in standard desktop chat but not during Cowork sessions.
This regression started after an auto-update to 1.24012.1; it was working fine before, with no changes to the config. Toggling the connector, re-saving directory settings, and restarting the app did not resolve the problem. Please prioritize this issue!
This blocks a production GraphRAG pipeline built on the Filesystem connector -highly frustrating!

Same issue here. Adding my data points since they match the reported signature exactly.

Environment

• Claude Desktop 1.24012.1 (Electron 42.7.0), macOS (Darwin 25.5.0), Apple Silicon
• First-party Filesystem extension ant.dir.ant.anthropic.filesystem, bundled @modelcontextprotocol/server-filesystem, running on built-in Node ("Using built-in Node.js for MCP server: Filesystem")
• Extension enabled, one allowed directory configured, directory exists with normal permissions
• Started failing 2026-07-21; worked normally before that

Symptom
Every Filesystem tool call fails instantly in the chat UI with Failed to call tool "<name>". Expanding the tool result in the transcript shows only:

Error
Tool execution failed

This affects all Filesystem tools, including list_allowed_directories (takes no arguments, touches no path), which rules out path validation, directory config, and OS-level file permissions.

Log evidence
The handshake round-trips cleanly, then nothing:

2026-07-22T16:46:42.995Z [Filesystem] [info] Initializing server...
2026-07-22T16:46:43.666Z [Filesystem] [info] Server started and connected successfully
2026-07-22T16:46:43.884Z [Filesystem] [info] Message from client: method="initialize" id=0
2026-07-22T16:46:43.887Z [Filesystem] [info] Message from server: id=0 result
2026-07-22T16:46:43.892Z [Filesystem] [info] Message from client: method="notifications/initialized"
2026-07-22T16:46:43.893Z [Filesystem] [info] Message from client: method="tools/list" id=1
2026-07-22T16:46:43.895Z [Filesystem] [info] Message from server: id=1 result

Across many reproductions (each one producing the UI error), zero tools/call lines appear in mcp.log, mcp-server-Filesystem.log, or main.log. The failure is instant, not a timeout. The request dies client-side before reaching the server's stdio.

For contrast: in this same log file, entries from April–June 2026 (previous app version) show normal tools/call → result round-trips for the same extension and config, so logging of tools/call is expected when dispatch works.

Possibly related detail
mcp.log shows the app cycling the Filesystem server shutdown→init 3 times within ~30 ms at one point:

2026-07-22T15:43:13.354Z [info] [Filesystem] Shutting down server...
2026-07-22T15:43:13.375Z [info] [Filesystem] Initializing server...
2026-07-22T15:43:13.379Z [info] [Filesystem] Server started and connected successfully
2026-07-22T15:43:13.382Z [info] [Filesystem] Shutting down server...
2026-07-22T15:43:13.383Z [info] [Filesystem] Initializing server...
2026-07-22T15:43:13.386Z [info] [Filesystem] Server started and connected successfully

Ruled out on my machine

• Full quit (Cmd+Q) + relaunch — clean shutdown/reinit in logs, still no tools/call
• Fresh chat with all other connectors disabled, Filesystem toggled ON in the chat's tool selector
• Toggling the app's bypass-permissions preference off
• Allowed-directory config (re-checked on disk: exists, drwxr-xr-x, owned by my user)

Linux (Pop!_OS) repro as well, so add another distro to the list. One data point I haven't seen in-thread: the OAuth errors in main.log are a red herring and here's the hard proof — my last known-good session (200 successful tools/call) simultaneously logged session_stale_relogin 202×, authorize returned 403 84×, and "Claude Code access has not been granted for this account" 64×. So none of those are causal, which lines up with @fpl9000's $schema/Zod finding being the real cause. Flagging because Anthropic's own support chat is currently telling affected users the Claude-Code-access denial is the root cause and to buy a seat upgrade — it isn't.

Confirming on a second machine: macOS 15.4.1, Apple Silicon, Desktop 1.24012.1, same 2026-07-21 onset, no configuration change.

Mine is a manually configured stdio filesystem server rather than the Directory extension, and it shows the identical symptom — so both configuration paths reproduce it.

Three additional eliminations beyond the list above:

• Not directory-specific: reproduced across four separately-named server instances pointed at three different allowed directories, including /tmp.
• Not the package: driving the same server version directly over stdio from a terminal, with the same arguments, returns a correct result for the same zero-argument call that fails inside Desktop.
• Not macOS TCC: explicitly granting the folder permissions in System Settings changed nothing.

Server versions 2026.7.4 and 2026.7.10 both fail. A non-filesystem control connector dispatched successfully in the same session, matching your control result.

Adding a data point that widens this beyond Filesystem-type servers.

Same symptom, different server class: I'm hitting the identical dispatch failure on a remote Streamable HTTP MCP server (mabl's cloud MCP at https://mcp.mabl.com/mcp), reached through mcp-remote 0.1.37 as a stdio bridge - not a Filesystem extension.

Environment matches the report:

• Claude Desktop macOS, app 1.24012.1
• Started 2026-07-21, no config change on my end
• Claude Code CLI on the same machine, same server, works fine
• Running mcp-remote by hand in the terminal against the same URL completes the handshake and lists tools fine

Mechanism, confirmed from mcp-remote's own debug log (~/.mcp-auth/mcp-remote-<ver>/*_debug.log): initialize, notifications/initialized, tools/list, and prompts/list all go out and come back with results. The OAuth token is present and not expired. When I invoke any tool, there is no tools/call line in the debug log at all - the request never reaches the bridge, so it never hits the transport. The UI shows an instant "Failed to call tool <name>" toast, no timeout.

So this isn't limited to Filesystem servers or the bundled extension - a remote HTTP server via mcp-remote reproduces the same client-side routing regression in 1.24012.1. The common factor looks like Desktop dropping tools/call after a successful handshake, independent of server type or transport.

Same issue on macOS — confirming client-side dispatch is where it dies.

Environment:

Claude Desktop on macOS, Apple Silicon (Mac mini)
Filesystem server launched via npx -y @modelcontextprotocol/server-filesystem /Users/<me>/Unity/WITD
Other local stdio connectors present in the same app: Blender (works), unity-mcp

Symptoms (identical to this report):

Every filesystem tool call fails instantly with the generic toast: Failed to call tool "list_allowed_directories" / Failed to call tool "list_directory" / Failed to call tool "read_text_file"
Not a timeout — failure is immediate

Server is provably healthy:

Piping a raw request to a manually-spawned instance returns a correct result instantly:
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_directory","arguments":{"path":"/Users/<me>/Unity/WITD"}}}' | npx -y @modelcontextprotocol/server-filesystem /Users/<me>/Unity/WITD

→ returns the full directory listing, no error

ps aux confirms the app-spawned server process is alive and pointed at the correct path

Logs confirm the call never leaves the client:

mcp-server-filesystem.log: clean lifecycle — Initializing server → Server started and connected successfully → initialize → notifications/initialized → tools/list with a valid result — then nothing. No tools/call line ever appears.
mcp.log: last filesystem entry is the tools/list result. No dispatch attempt, no error for any subsequent call.
main.log: only routine memory/plugin logging around the failure timestamps — no MCP error.

Additional data points:

Persists across full Cmd+Q relaunch and across brand-new conversations.
Killing the server process and letting the app respawn it does not fix it (respawn is clean in the log, calls still dropped).
A different local stdio connector (Blender) in the exact same app instance/session works normally — so this is per-connector, not a blanket app failure.

Conclusion matches the report: the tools/call is dropped inside Claude Desktop's client-side routing after a successful handshake, before it's ever written to the server's stdin. Server and config are not the problem.

Confirming this on Windows — not macOS-specific.

Same symptom, same build. Claude Desktop 1.24012.1 (0adcae), built 2026-07-21T20:59:53, Windows 11.

The first-party Filesystem connector completes the full handshake and answers tools/list, but tools/call is never dispatched — every call fails instantly with "Failed to call tool," including the app's own health probe. mcp.log shows healthy server lifecycles across repeated reconnects, every handshake answered in milliseconds, and never a single tools/call:

2026-07-22T06:52:29.538Z [Filesystem] Initializing server...
2026-07-22T06:52:29.573Z [Filesystem] Server started and connected successfully
2026-07-22T06:52:29.611Z [Filesystem] Shutting down server...
2026-07-22T06:52:29.631Z [Filesystem] Initializing server...
2026-07-22T06:52:29.665Z [Filesystem] Server started and connected successfully
2026-07-22T06:52:29.812Z [Filesystem] Message from client: method="initialize" id=0 params
2026-07-22T06:52:30.690Z [Filesystem] Message from server: id=0 result
2026-07-22T06:52:30.692Z [Filesystem] Message from client: method="notifications/initialized"
2026-07-22T06:52:30.734Z [Filesystem] Message from client: method="tools/list" id=1 params
2026-07-22T06:52:30.741Z [Filesystem] Message from server: id=1 result
// no tools/call ever follows, across multiple sessions

The rapid init/shutdown cycling above is from toggling and reinstalling the connector — each cycle re-initializes cleanly and answers tools/list, so the server is demonstrably healthy every time; calls still never dispatch.

Onset was 2026-07-21, coinciding with the auto-update to 1.24012.1, with no config change on my side. Same mitigations as the OP failed: uninstall/reinstall the connector, full device restart, sign out and back in. Additional data point: it reproduces across two separate devices signed into the same account, which rules out local state as the cause and points squarely at the app-version regression.

Same issue macOS 15.7.7, Claude Desktop 1.24012.1.

Same signature: server completes initialize -> notifications/initialized -> tools/list
successfully, then no tools/call frame is ever written to the transport. Every invocation
fails instantly with a Failed to call tool "<name>" toast while the connector shows as
healthy and enabled.

Setup: custom-named server in claude_desktop_config.json (not the bundled extension),
npx -y @modelcontextprotocol/server-filesystem with a single allowed directory. Node/npx
resolved at /usr/local/bin/npx.

Timeline, from ~/Library/Logs/Claude/mcp.log (UTC):

• Last successful tools/call: 2026-07-21T14:46:36Z. Hundreds of calls prior with zero errors.
• Every session from 2026-07-21T22:29Z onward: clean handshake, tools/list returns in

single-digit ms, then zero tools/call entries for the life of the session.

• grep "tools/call" ~/Library/Logs/Claude/mcp.log returns nothing dated after

2026-07-21T14:46Z.

So the break window is 2026-07-21T14:46Z to 2026-07-21T22:29Z.

One detail worth noting: My /Applications/Claude.app bundle mtime is
2026-07-22T03:09:22Z, roughly 4.5h after the break had already begun. That suggests an
earlier update inside the window is the culprit and the later one was a second update that
did not fix it, consistent with the report here that a same-day follow-up update changed
nothing.

Ruled out on my side, in this order:

• Path correctness. Server logs the resolved allowed directory correctly on every start.
• Filesystem permissions / iCloud eviction. list_allowed_directories reads nothing from

disk, it only echoes back launch args, and it fails identically. Full Disk Access is not
the issue.

• npx PATH resolution. Logged as resolved, server starts.
• Server crash or startup failure. Handshake completes every time, process sits idle.
• Duplicate or stale registration. Deleted the server from claude_desktop_config.json,

rebuilt the config from scratch, re-added a single entry. No change.

• Server name collision. Renamed the server key to remove the hyphen. No change.
• Stale client-side tool handles. Re-enumerated tools after restart. No change.
• Full app quit and relaunch, multiple times.

Just started working for me. @evanhourigan

Working for me now. No desktop app update was pushed, but my test to read external cloud files was a success (for the first time in about 24 hours).

Data point on timing, since this is looking like a rollback rather than a client fix: confirmed clean again on my end as of ~24h after last posting, with no client update on my side.

I posted the third-server corroboration on #79971 yesterday (apple-notes-mcp, both a pinned 2.5.11 build and npx-resolved 2.6.8, both failing identically — same handshake-then-silence fingerprint as here).

Just re-ran health-check/doctor against both of those same server instances, same session, no app relaunch since my last failing attempt yesterday:

✓ All checks passed
  ✓ notes_app: Notes.app is accessible
  ✓ permissions: AppleScript automation permissions granted
  ✓ accounts: Found 1 account(s): iCloud
  ✓ operations: Basic operations working (19 note(s) in iCloud)
  ✓ full_disk_access: Granted (checklist features available)

Both instances pass now — pinned and latest, identical output.

Environment, unchanged since my last comment:

• Claude Desktop 1.24012.1 (same build, no update landed)
• macOS 26.5.2 (build 25F84)
• No config edits, no app reinstall, no relaunch between the failing attempts yesterday and the passing ones today

Since nothing changed client-side on this machine, a client patch doesn't explain it — this fits @tiger-media's staged-rollback theory in #79992 better than a binary fix. If anyone's tracking the rollout timing there, "clean again with zero local changes, ~24h after onset" from a third, unrelated MCP server might be a useful data point. @aaronwllms reported the same thing yesterday for the Filesystem connector — sounds like this may be rolling back per-account rather than all at once.

Confirmed working again as of 6:25 MT on Desktop build Claude 1.24012.1. The same setup that failed all morning - a remote Streamable HTTP server (mabl) via mcp-remote - now dispatches tools/call normally. The call shows up in the mcp-remote debug log and returns a result, where earlier there was no tools/call line at all. No config change on my end, so this looks resolved server-side or via a Desktop update rather than anything users did.

Working on my side too. No updates, just restarted.

Resolved as of 2026-07-22. Posting the correction because it invalidates the main diagnosis in my report.

This was not a client build regression. It broke on 1.24012.1 and it now works on 1.24012.1, with no app update, no reinstall, and no configuration change between the failing and working states. I did nothing; it simply started dispatching again. Several other reporters have described the same spontaneous recovery in the same window.

The "Last Working Version: 1.22209.3 -> 1.24012.1" framing in my report was correlation, not cause. The auto-update landed the same day the break began, which made it look like the culprit. Recovery on the identical build rules that out and points at something server-side in the dispatch path.

Verified working: list_allowed_directories returns both configured paths, and list_directory returns real contents. tools/call entries now appear in mcp.log where previously none ever did.

Two things this leaves on the record for anyone who lands here:

1. If your Filesystem connector completes its handshake and answers tools/list but every tools/call dies instantly with no log entry on either side, no local action will fix it. The full elimination list is in the report above: permissions, reinstall, restart, sign-out, and a complete wipe of the app and all local state were all tested and all failed. Save yourself the evening.

1. Because the cause was not local, it can recur without any change on your machine.

Closing as completed. Happy to reopen if it comes back.

Confirmed fixed for me too (I mentioned this on #79992 rather than here).

Did Anthropic actually own that there was an issue or are they just pretending it never happened? This was a showstopper for us, and killed productivity for two ppl for an entire working day. It's on us to have processes that rely so heavily on Claude Desktop working as configured, I get that, but some indication of remorse re the situation from Anthropic would be... professional.

...

How the Fix Applied Without an Application Release
There are a few reasons why the problem resolved without showing a visible version number change in your desktop application settings. The approach is called Progressive Delivery: An umbrella term for software delivery workflows that decouple code deployment from feature release, allowing controlled rollouts and instant rollbacks.

1. Independent Extension Updates

The filesystem connector functions as a separate extension module. These local MCP server packages update independently from the main Claude Desktop application bundle. A quiet background update to the filesystem extension corrected the tool schema format, allowing the Zod schema validator to pass without requiring a desktop app update.

1. Remote Feature Flags and Configuration Updates

Anthropic uses remote configuration toggles for client behavior. If engineers updated a remote feature flag or client side validation parameter on their servers, your desktop app picked up the updated instructions immediately upon connecting to the network.

1. Dynamic Asset Hotfixes

Minor patches to bundled internal scripts can be downloaded quietly when the application starts or reinitializes, resolving internal parsing failures without triggering a full app installation cycle.

Same signature reproduced on Windows — not macOS-specific.

Environment: Claude Desktop for Windows, app Claude 1.24012.1.0, first-party
Filesystem extension (Directory-installed), Windows [Version 10.0.29617.1000].

Timeline from %APPDATA%\Claude\logs\mcp.log (timestamps UTC):

• Last successful dispatch: 2026-07-19T21:01:30Z — four consecutive

tools/call messages (ids 2–5), each answered with result(1 blocks)
in single-digit milliseconds.

• First broken session: 2026-07-22T12:02Z — full handshake completes

(initialize → notifications/initialized → tools/list → result),
then nothing. Reproduced identically at 2026-07-22T12:50Z and
2026-07-23T11:50Z (the latter after a clean shutdown/restart at 11:49).

• In today's session, three list_allowed_directories calls issued from

a chat each failed instantly in the UI; none produced a tools/call
entry in mcp.log or mcp-server-Filesystem.log.

• Select-String -Path "$env:APPDATA\Claude\logs\*.log" -Pattern "tools/call"

confirms the last tools/call anywhere in my logs is 2026-07-19T21:01:30Z.

So my break window is 2026-07-19 21:01Z → 2026-07-22 12:02Z, consistent
with the ~2026-07-21 onset reported above. No configuration change on my
side; allowed directories and permissions untouched. Toggling the
extension and full app restarts did not resolve it.

One observation that may or may not be relevant: in every broken session
the server takes ~5s to answer initialize, while tools/list is
answered in ~5–25ms. In the working 2026-07-19 sessions there is no such
delay visible. The server is otherwise healthy throughout.

Today's session:

2026-07-23T11:50:00.556Z [info] [Filesystem] Initializing server...
2026-07-23T11:50:00.582Z [info] [Filesystem] Server started and connected successfully
2026-07-23T11:50:00.641Z [info] [Filesystem] Message from client: method="initialize" id=0 params
2026-07-23T11:50:06.003Z [info] [Filesystem] Message from server: id=0 result
2026-07-23T11:50:06.003Z [info] [Filesystem] Message from client: method="notifications/initialized"
2026-07-23T11:50:06.009Z [info] [Filesystem] Message from client: method="tools/list" id=1 params
2026-07-23T11:50:06.012Z [info] [Filesystem] Message from server: id=1 result
// nothing further — the three failed UI calls left no trace

Take a look at this workaround -

MCP TypeScript SDK generates tool inputSchemas via zod-to-json-schema, which stamps $schema: draft-07 into every tool and (SDK >=1.26) adds outputSchema/annotations/execution fields.

The updated Claude Desktop validates tool definitions strictly at tools/call time and rejects these — the server spawns and handshakes fine, tools/list succeeds, but every tools/call fails app-side before reaching the transport.

https://github.com/modelcontextprotocol/servers/issues/4545#issuecomment-5056557933

Update — resolved on my end (Windows)

Following up on my earlier comment. The issue is now resolved for me. Two things happened around the same time, so I can't say with certainty which one fixed it, but my best guess is the first:

1. Ran Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser in PowerShell (previous policy was likely the Windows default Restricted)
2. Updated Claude Desktop to the latest available build shortly after

After both, tools/call now reaches the filesystem server correctly and returns results as expected — confirmed with list_allowed_directories and list_directory, both working.

If the PowerShell execution policy is indeed the cause (or a contributing factor), it would make sense with the original symptom: the handshake (initialize, tools/list) always succeeded, but tools/call never reached the server — consistent with something silently failing in a script-based step during dispatch on Windows, rather than a protocol-level or server-level issue.

Might be worth others on Windows checking their execution policy (Get-ExecutionPolicy -List) as a potential workaround while a proper fix is investigated. Happy to provide more details if useful.

Indded I can confirm too that it has been fixed on version 1.24012.9.0 on Windows 29617.1000 .
Nothing done by me - has been fixed by Anthropic in this update.