### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Summary This is a regression introduced in Claude Desktop 1.24012.1.<

[BUG] Claude Desktop (Windows): regression in 1.24012.1 — tools/call never dispatched to Filesystem extension, handshake healthy, zero trace in any log

Status Closed — duplicate

Reported on v2.1.216

Maintainer reply None cached

Activity 7 comments · opened Jul 22, 2026 · closed Aug 19, 2026

Preflight Checklist

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

What's Wrong?

<html>
<body>
<html><head></head><body>
<hr>
<h3>Summary</h3>
This is a regression introduced in Claude Desktop 1.24012.1. The same machine and
the same vault worked continuously for four days on 1.24012.0, including the evening of
2026-07-21. Every filesystem tool call has failed since the update to 1.24012.1.
Note that #80002 (macOS, open) reports identical symptoms on this same build,
1.24012.1, suggesting a cross-platform regression in Desktop's MCP dispatch layer
rather than anything platform-specific.
<pre><code>2026-07-21 20:36:49 [info] Starting app { appVersion: '1.24012.0', isPackaged: true,
platform: 'win32', arch: 'x64',
nodeVersion: '24.18.0' } ← tool calls worked

2026-07-22 00:37:28 [info] Starting app { appVersion: '1.24012.1', isPackaged: true,
platform: 'win32', arch: 'x64',
nodeVersion: '24.18.0' } ← earliest 1.24012.1
launch; all tool
calls fail from here
</code></pre>
The update installed unattended between 20:36:49 on 2026-07-21 and 00:37:28 on
2026-07-22. No filesystem tool call has succeeded at any point after that boundary,
across three separate server configurations.
<h3>The JSON-RPC id sequence stops at 1 after the update</h3>
This is the clearest signal available. Request ids increment per session: <code>id=0</code> is
<code>initialize</code>, <code>id=1</code> is <code>tools/list</code>, and <code>id=2</code> onward are <code>tools/call</code>.
Before 1.24012.1 — sessions run deep into the call range:
<pre><code>2026-07-21T07:33:08.891Z method="tools/call" id=2 ← session start
... 66 consecutive dispatched calls ...
2026-07-21T19:34:12.323Z method="tools/call" id=67 ← LAST EVER SUCCESSFUL CALL
</code></pre>
Earlier sessions reach id=102 and id=119 similarly.
After 1.24012.1 — every session terminates at <code>id=1</code>:
<pre><code>07:34:17.247 method="initialize" id=0 ✓ answered
07:34:17.578 method="notifications/initialized" ✓
07:34:17.579 method="tools/list" id=1 ✓ answered
← no id=2. Ever. In any session.
</code></pre>
The client is not failing to deliver <code>tools/call</code> — it never issues one. No request
id beyond 1 is generated after the handshake completes.
Note: mcp logs are UTC; <code>main.log</code> is local time (BST, UTC+1). The final successful call
at 19:34:12Z corresponds to roughly 20:34 local, about two minutes before the 20:36:49
restart on 1.24012.0.
<code>mcp-server-filesystem.log</code> and <code>mcp.log</code> both contain thousands of <code>tools/call</code> entries
prior to the update, confirming these logs do record dispatch when it occurs. The
complete absence of <code>tools/call</code> after 1.24012.1 is a real absence of dispatched calls,
not a logging gap.
<h3>Preflight Checklist</h3>
<ul>
<li>[x] I have searched existing issues</li>
<li>[x] This is a single bug report</li>
<li>[x] I am using the latest version of Claude Desktop</li>
</ul>
<h3>What's Wrong?</h3>
On Claude Desktop for Windows, the Filesystem connector completes the full MCP
handshake (<code>initialize</code> → <code>notifications/initialized</code> → <code>tools/list</code>) successfully,
but <code>tools/call</code> messages are never dispatched to the server. Every tool call
fails instantly in the UI. No <code>tools/call</code> entry ever appears in
<code>mcp-server-filesystem.log</code>. The request never becomes a message on the transport.
The server sits idle and healthy.
This reproduces across three distinct server configurations, including the
first-party extension installed through Settings → Extensions.
<code>main.log</code> shows <code>Extension filesystem not found in installed extensions</code> on startup, but
this warning predates the failure by days and is present throughout normal operation —
see the log section. It is not the cause.
<h3>What Should Happen?</h3>
After a successful handshake, Claude Desktop should dispatch <code>tools/call</code> to the
Filesystem server. If dispatch cannot be delivered, it should fail with a distinct,
logged error rather than failing silently with no trace on either side.
<h3>Environment</h3>

The slow handshake under <code>npx</code> was package resolution on every launch, and is fixed by
invoking <code>node</code> directly. But with the handshake completing in 364ms, the full ~23s
window is wide open and calls still fail with no trace. Dispatch failure is not
timing-dependent.
<h3>What has been ruled out</h3>
<ul>
<li>Allowed-directory config — the server itself reports all three directories correctly.</li>
<li>A specific drive — <code>D:\wamp64\www</code> fails identically to <code>G:\MasterVault</code>.</li>
<li>Filesystem access entirely — <code>list_allowed_directories</code> takes no arguments and
touches no file. It fails exactly like a path-specific read.</li>
<li>Stale transport — full app restart, no change.</li>
<li>Orphaned server processes — full machine reboot, no change.</li>
<li>Slow drive / late mount — reboot with drives confirmed mounted, no change.</li>
<li>Node version — v24.18.0.</li>
<li><code>npx</code> stdio fragility — fixed; symptom persists.</li>
<li>Extension registration — the namespace change under config 3 proves the extension
registered. Symptom persists. This is the theory #22299 favours, and it does not hold here.</li>
<li>The <code>not found in installed extensions</code> warning — present on every startup for days
before the break, including sessions that dispatched 66 consecutive calls successfully.
Also fires for an unrelated, healthy server (<code>unityMCP</code>). Not causal.</li>
<li>Duplicate/conflicting registration — a real defect was found and fixed (both
<code>Filesystem</code> and <code>filesystem</code> registered and thrashing). Symptom persists on a single
clean registration.</li>
</ul>
Notably, tool definitions reach the client correctly — the full schema list is
available from <code>tools/list</code> in every configuration. The server→client path works. Only
client→server <code>tools/call</code> fails.
<h3>Is this a regression?</h3>
Yes. Last working version: 1.24012.0.
This machine ran four days of continuous filesystem work — a vault dashboard and
connected systems across <code>G:\MasterVault</code> — with no MCP problems, up to and including
the evening of 2026-07-21 on 1.24012.0. The first failure occurred the following
morning on 1.24012.1. Nothing else on the machine changed: same Node (24.18.0), same
allowed directories, same server package.
Last successful <code>tools/call</code>: <code>2026-07-21T19:34:12.323Z</code> (id=67). That session had
dispatched 66 consecutive calls without incident. Zero calls have been dispatched since,
across every session and all three configurations.
<h3>Related</h3>
<ul>
<li>#22299 — same symptom, Windows, closed. Ruled out its race-condition and registration theories above.</li>
<li>#80002 — same symptom, macOS, first-party extension, currently open.</li>
<li>#14807 — same symptom, Windows.</li>
</ul></body></html>
</body>
</html>

What Should Happen?

After a successful handshake, Claude Desktop should dispatch tools/call to the Filesystem server. If dispatch cannot be delivered, it should fail with a distinct, logged error rather than failing silently with no trace on either side.

Error Messages/Logs

Steps to Reproduce

Configure the Filesystem server by any of the three methods below.
Confirm the handshake completes in %APPDATA%\Claude\logs\mcp-server-filesystem.log.
Ask Claude to list or read anything inside an allowed directory.
Observe: the call fails immediately, and no tools/call line appears in the log.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.24012.0

Claude Code Version

2.1.216 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗

6 Comments

Hannibal2404 · 1 month ago

Also affected on Windows,

App 1.24012.1.0, Windows 11 26200, Node v24.18.0 (same build as yours, so not a Node difference), @modelcontextprotocol/server-filesystem launched directly with node.

In Chat every call fails instantly, including the parameterless list_allowed_directories. The server log for a fresh instance ends after initialize → notifications/initialized → tools/list — no tools/call, no id ≥ 2, no error in any log, matching your finding that the request is never generated.

So the transport and the server integration look fine in general;

svnikolov79-cell · 1 month ago

Confirming the same regression on 1.24012.1 (0adcae), Windows 11 MSIX install.

Identical signature: handshake completes (initialize → tools/list answered),
then zero tools/call entries in mcp-server-Filesystem.log and mcp.log across
hours of testing, fresh chats, full tray restarts, and sign-out/sign-in.
Affects both configured local servers (filesystem + one custom stdio server),
so it's not server-specific.

Two data points that may help:

Also reproduces with the built-in Node runtime — main.log shows

"Using UtilityProcess for extension Filesystem:
appConfig.isUsingBuiltInNodeForMcp is true and built-in node is compatible"
and the server logs "Secure MCP Filesystem Server running on stdio" with
allowed directories parsed correctly. So the dispatch failure is upstream
of the Node invocation path entirely.

Same server binary, same entry point, same paths registered in Claude Code

CLI (v2.1.148) → connected, tools/call works normally. The defect is
isolated to Desktop's dispatch layer.

thebusinessvet · 1 month ago

Also affected — Windows 11, MSIX (Store) install, manually configured @modelcontextprotocol/server-filesystem via the npm global .cmd shim (Desktop wraps it in cmd.exe automatically). Fourth distinct configuration alongside the three in the original report.

The 1.24012.1 boundary doesn't hold on my machine — I broke while still on 1.24012.0, and updating to 1.24012.1 changed nothing.

MCP logs are UTC, main.log is local (UTC-4 here; the 1.24012.1 launch at 11:18:12 local matches the MCP session at 15:18:26Z).

2026-07-21 20:21:25.536Z  tools/call id=143   ← last ever successful call
2026-07-22 11:17:21 local Starting app { appVersion: '1.24012.0' }
2026-07-22 11:17:38 local beforeQuitForUpdate — going down for update
2026-07-22 11:18:12 local Starting app { appVersion: '1.24012.1' }
                          [updater] Version changed since last launch: 1.24012.0 → 1.24012.1

That's roughly 19 hours of zero dispatched calls on 1.24012.0 before the update landed, and identical behaviour after it. Same signature throughout: initialize → notifications/initialized → tools/list all answered, then no id ≥ 2 in any session. The break coincides with an unclean app termination on 2026-07-21 (no shutdown lines logged), not with a version change.

If others can check their own main.log version history against their last successful tools/call, it's worth confirming whether the build is really the trigger — this looks closer to #80210, which reports a ~2026-07-21 regression that appears account-gated.

Also: remote connectors still dispatch normally. In the same chat session where list_allowed_directories and list_directory both failed instantly, a Google Drive connector call was issued and returned results. Only local stdio servers are affected, which may help narrow where in the dispatch layer the defect sits.

One possible mechanism — local MCP tools are announced to a remote bridge rather than being called directly:

[localMcpBridge] ensureAllConfiguredConnected failed — announcing partial/empty set
                 { error: 'Error: ensureAllConfiguredConnected timed out after 10000ms' }
[localMcpBridge] announcing filesystem: 14 tool(s)
[remote-tools-device] connecting DO bridge with: ... (+0 grand-prix, +14 local-mcp)
[remote-tools-device] connecting wss://bridge.claudeusercontent.com/devices/.../bridge

If tools/call routes back through that bridge, that would explain discovery succeeding while invocation never reaches the transport.

Confirming what others have found: Claude Code CLI against the same server and same paths works normally. The defect is isolated to Desktop's dispatch layer.

IdovaPrime · 1 month ago

Correction: the version-regression conclusion in this report doesn't hold.

I filed this against 1.24012.1 because my last successful tool call was on 1.24012.0 and the failure began after an unattended overnight update. That correlation is real and I stand by the evidence below it. The causal claim isn't.

The fault cleared roughly 24 hours later on its own. main.log confirms 1.24012.1 was running throughout, both while broken and after recovery — no patch was applied, and my attempt to launch the spare 1.24012.0 build never actually took effect. Same binary, broken then working.

That points away from the shipped binary and toward something delivered remotely: a server-side rollout, an extension update, or a feature flag. main.log loads [growthbook] features on every start, which seems the obvious place to look.

What still stands, and is the part worth keeping for triage:

The signature is that tools/call is never issued. The JSON-RPC id sequence stops dead at id=1 (tools/list) in every affected session, against ids reaching 67, 102 and 119 in sessions before the break. Nothing appears in the server log because no request is ever sent.
Four configurations failed identically: npx via cmd.exe; direct node against a global install; the first-party Filesystem extension alongside a config entry; and the extension alone with the config cleared.
Ruled out: allowed-directories config, a drive-specific fault (a second drive failed the same way), stale transport (app restart), orphaned processes and late-mounting drives (full reboot), Node version, extension registration, and duplicate registration.
UtilityProcess Check: Extension <name> not found in installed extensions is benign noise. It fires throughout healthy operation and for unrelated servers. It is not a lead.

If anyone else hits this: check whether calls are being issued before touching local config. I lost a day to config that was never the problem.

Shimrod-ABM · 1 month ago

Hope this helps.
Fix: go to Claude Desktop Settings → Advanced → disable "Use Built-in Node.js for MCP" — tools/call dispatches normally after that.