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

[evanhourigan]

Preflight Checklist

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

What's Wrong?

On Claude Desktop for macOS (app 1.24012.1), the first-party Filesystem
connector (extension id `ant.dir.ant.anthropic.filesystem`) completes the
full MCP handshake (initialize -> notifications/initialized -> tools/list)
successfully, but tools/call messages are never dispatched to the server.

Every tool call fails instantly in the UI with "Failed to call tool
<name>". No tools/call entry ever appears in ~/Library/Logs/Claude/mcp.log,
mcp-server-Filesystem.log, or main.log. The request never becomes a message
on the transport. The server sits idle and healthy.

This is distinct from #22299 in one way that may matter: that report's
leading theory was the main.log warning "Extension filesystem not found in
installed extensions", i.e. Desktop failing to route calls for a server it
does not recognise as an installed extension. My case uses the first-party
Directory-installed extension, which IS registered, and reproduces the same
symptom. So the failure is not limited to manually configured stdio servers
in claude_desktop_config.json.

Began 2026-07-21 with no configuration change on my side. Allowed
directories and per-tool permissions are byte-identical to when it worked.

Related: #22299, #22319, #66726.

What Should Happen?

After a successful handshake, Claude Desktop should dispatch tools/call to
the Filesystem extension. If dispatch cannot be delivered, it should fail
with a distinct, logged error rather than a generic "Failed to call tool"
with zero trace on either side.

Error Messages/Logs

UI error:
    Failed to call tool "list_allowed_directories".
    Failed to call tool "list_directory".

    mcp.log — full lifecycle, healthy, and nothing after tools/list:

    [Filesystem] Initializing server...
    [Filesystem] Using built-in Node.js for MCP server: Filesystem
    [Filesystem] Server started and connected successfully
    [Filesystem] Message from client: method="initialize" id=0 params
    [Filesystem] Message from server: id=0 result
    [Filesystem] Message from client: method="notifications/initialized"
    [Filesystem] Message from client: method="tools/list" id=1 params
    [Filesystem] Message from server: id=1 result
    // <- nothing further. No tools/call ever arrives, despite repeated calls.

    main.log — app side also reports a clean, healthy connection:

    [info] MCP Server connection requested for: Filesystem
    [info] Launching MCP Server: Filesystem
    [info] Checking if UtilityProcess should be used for extension Filesystem
    [info] Using UtilityProcess for extension Filesystem: appConfig.isUsingBuiltInNodeForMcp is true and built-in node is compatible
    [info] [LocalMcpServerManager] Connected to Filesystem (14 tools)
    [info] [localMcpBridge] announcing Filesystem: 14 tool(s)
    [info] [UtilityProcess stderr] Secure MCP Filesystem Server running on stdio
    [info] [UtilityProcess stderr] Client does not support MCP Roots, using allowed directories set from server args: [ '/Users/evan/code', '/Users/evan/.claude' ]

    A grep of main.log for tool call errors returns nothing at all. There is no
    exception, no rejection, no dispatch attempt logged anywhere.

    Note: the extension reinstall bumped v2026.7.4 -> v2026.7.10. Both fail
    identically.

    Post-wipe, on the fresh install, the server is demonstrably healthy across
    repeated reconnects while calls continue to fail:

    2026-07-22T01:46:36.995Z [Filesystem] Initializing server...
    2026-07-22T01:46:37.018Z [Filesystem] Server started and connected successfully
    2026-07-22T01:46:37.302Z [Filesystem] Message from client: method="tools/list" id=1 params
    2026-07-22T01:47:23.159Z [Filesystem] Initializing server...
    2026-07-22T01:47:23.170Z [Filesystem] Server started and connected successfully
    2026-07-22T01:47:23.583Z [Filesystem] Message from client: method="tools/list" id=1 params
    2026-07-22T01:49:12.019Z [Filesystem] Initializing server...
    2026-07-22T01:49:12.023Z [Filesystem] Server started and connected successfully
    2026-07-22T01:49:12.317Z [Filesystem] Message from client: method="tools/list" id=1 params

    Server startup is consistently under 25ms and tools/list is answered in
    roughly 300ms. There is no tools/call anywhere in the file.

Steps to Reproduce

1. Claude Desktop for macOS, app 1.24012.1.
2. Install the first-party Filesystem connector from the Directory.
3. Configure two allowed directories, save. Confirm in mcp.log that the
   server initializes and answers tools/list.
4. Ask Claude to list a directory inside an allowed path, or simply
   re-enable the connector and let the app's own post-enable health probe
   of list_directory run.
5. Observe: instant "Failed to call tool". No tools/call in mcp.log,
   mcp-server-Filesystem.log, or main.log.

Note step 4: the app's OWN health probe of list_directory also fails on
re-enable, so this reproduces independent of any model-issued tool call.

Attempted and did NOT resolve it:
- Re-saving allowed directories
- Cycling per-tool permissions (all were already Always Allow)
- Toggling the connector off and on (clean re-init in the log each time)
- Uninstalling and reinstalling the extension (v2026.7.4 -> v2026.7.10)
- Full app restart
- Signing out of Claude Desktop and back in
- Closing all claude.ai browser tabs, then signing out of claude.ai
- Full wipe: Application Support/Claude, Logs/Claude,
  Caches/com.anthropic.claudefordesktop(+.ShipIt),
  Preferences/com.anthropic.claudefordesktop.plist,
  HTTPStorages/com.anthropic.claudefordesktop, then reinstall from
  claude.ai/download

Control: a non-Filesystem connector call in the same session dispatched and
returned a valid result, so the session itself was able to execute tools.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Last working: app 1.22209.3     Broken: app 1.24012.1      Version history from main.log:     1.20186.0 -> 1.20186.9 -> 1.21459.0 -> 1.21459.3 -> 1.22209.3 -> 1.24012.1      The break began 2026-07-21 with no configuration change on my side, and     1.24012.1 is the build in place when it started. Claude Desktop     auto-updates on quit and restart, so the update was not a deliberate     action on my part and there is no supported way to roll back.

Claude Code Version

Not applicable — this is Claude Desktop's MCP client, not Claude Code.     Claude Desktop app 1.24012.1, Electron 42.7.0.     (Claude Code CLI on the same machine is healthy and unaffected.)

Platform

Other

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Key observations:

1. The server is healthy at every stage: starts, loads both allowed
   directories, answers tools/list in single-digit milliseconds.
2. The failure is instant, not a timeout. This is not the ~4-minute hang
   described in #66726.
3. Zero diagnostic signal. No tools/call on the server side, and no error,
   rejection or dispatch attempt on the app side. The generic UI string is
   the only evidence the call happened at all.
4. The app's own post-enable health probe fails the same way, so this is
   not specific to model-issued calls.
5. Unlike #22299, this is a first-party Directory-installed extension, so
   "not found in installed extensions" does not explain it.
6. Survives a complete wipe and reinstall of the app and all of its
   local state, which suggests state outside the app bundle and
   Application Support, or a server-side extension registration.
7. Post-wipe, on a completely fresh install with a newly installed
   extension, a list_allowed_directories call issued inside the ~23-second
   window described in #22299 ALSO failed, twice consecutively. So the
   narrow post-handshake window is not a workaround in this case, and the
   failure is not a race against a warm-up period.

Impact: the connector is the primary path for a working file-editing
workflow. Losing dispatch with no error surface makes it undiagnosable from
the user side.

main.log
cowork_vm_node.log
cowork_vm_swift.log
claude.ai-web.log
coworkd.log
swift.log
mcp.log
mcp-server-Filesystem.log
vzgvisor.log
unknown-window.log
ssh.log
chrome-native-host.log
main1.log

[Antonio-Tsai]

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 [BUG] Claude Desktop MCP: tool call responses dropped by client after first successful round-trip (Windows, regression in CCD v2.1.22) #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.

[niko-java]

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//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.

[MN8989]

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).

[PhasonMatrix]

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.

[tyang4-ai]

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.

[riotbutjp]

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.

[Kangooaus]

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.

[myNickWasStolen]

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?

[hollycrabb]

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)

4. Open a new conversation
5. 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\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

2. 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.

[Weblitech]

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.

[tuharju]

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.

[luwar]

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.