[BUG] Claude Desktop stops dispatching tools/call to local stdio MCP servers for all instances launched after ~18:29 UTC 2026-07-21; remote connectors and Claude Code unaffected

[DannyCarlton]

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?

Summary: Local stdio MCP servers complete initialize and tools/list normally, but no tools/call is ever written to the server's stdin. The model's tool attempt surfaces as "Tool execution failed" (1.22209.3.0) / "Failed to call tool" (1.24012.0.0). Reproduced on two independent Windows 11 machines.

Timeline (all UTC, from mcp.log):

Machine A: last successful tools/call id 207 at 18:24:08 on 07-21, in a session started earlier; first app restart at 18:29:35 → broken; broken ever since
Machine B: idle from 16:01:14; first launch after, at 18:34:20 → broken
Pattern: every instance started before ~18:29 UTC worked until closed; every instance started after fails. Consistent with a startup-fetched server-side change.

Ruled out by test: server package version (pinned known-good); a second no-argument memory server fails identically; bundled Filesystem extension off throughout; fresh sessions; client update 1.22209.3.0 → 1.24012.0.0 (failure survived it); full reboot.

Controls: Remote connectors (Google Drive) work in the same failing sessions. Claude Code v2.1.216 on the same machine, same account, same server binary dispatches tools/call normally.

Environment: Sideloaded MSIX from claude.ai/download (SignatureKind: Developer), package family Claude_pzs8sxrjxfjjc, Windows 11. Logs from both machines attached.

Minor log artifact: brief interleaved launches of "filesystem"/"Filesystem" at 19:09:40 on Machine A from toggling the bundled extension during testing — postdates the failure, noise not cause.

[NOTE: This summary was compiled by Claude Desktop (Fable 5, after several hours of troubleshooting the problem.]

What Should Happen?

When the model emits a tool call targeting a local stdio MCP server, Claude Desktop should write the tools/call request to the server's stdin and return the result — as it did for every session started before ~18:29 UTC on 2026-07-21, and as Claude Code v2.1.216 still does on the same machine, same account, and same server binary. Instead, the request is never written (server logs show initialize and tools/list succeed, then zero tools/call entries across thousands of attempts), and the UI surfaces "Failed to call tool" / "Tool execution failed."

Error Messages/Logs

Steps to Reproduce

Steps to reproduce:

1. On Windows 11, install Claude Desktop (sideloaded MSIX from claude.ai/download; reproduced on 1.22209.3.0 and 1.24012.0.0, package family Claude_pzs8sxrjxfjjc).

2. Configure any local stdio MCP server in claude_desktop_config.json. Reproduced with @modelcontextprotocol/server-filesystem (via npx and via a global npm install) and with a no-argument memory server -- the specific server does not matter.

3. Launch Claude Desktop and start a fresh conversation. Note in mcp.log that the server starts, completes initialize, and answers tools/list normally.

4. Ask Claude anything that triggers a tool call on that server (e.g. "list the contents of an allowed directory").

5. Observe: "Failed to call tool" in the UI; mcp.log shows no tools/call entry was ever sent to the server.

Reproduces 100% of the time on any Desktop instance launched after ~18:29 UTC 2026-07-21, on two independent machines. Instances launched before that time dispatched calls normally until closed (last success: tools/call id 207 at 18:24:08Z, five minutes before the first broken restart at 18:29:35Z). Same server binary, same account, Claude Code v2.1.216 on the same machine: works. Remote connectors (Google Drive) in the same failing Desktop session: work.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

v2.1.216

Platform

Other

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

CR2075-mcp.log
L830-mcp.log

[caelum29]

Corroborating data point from macOS (filed as #79933 before finding this issue — likely the same incident, observed at a different layer):

• Claude Desktop 1.24012.0, macOS 26.2 (Apple Silicon), local stdio .mcpb servers.
• Same onset window: persistent failures started the evening of 2026-07-21 (UTC); Claude Code CLI on the same machine/account/server binary is unaffected — matches your control.
• Same UI symptom: bare Failed to call tool "<name>", including Anthropic's bundled Filesystem extension (list_allowed_directories, read_multiple_files). Fresh conversations and full Cmd+Q restart don't recover.
• One difference in the observed layer: in my logs tools/call DOES reach the server and the server returns a result in <1s (mcp-server-*.log) — the failure shows up in claude.ai-web.log as the web layer failing to hand the result to the backend:

POST /api/organizations/<org>/chat_conversations/<conv>/tool_result
→ 404 {"error_code":"side_channel_waiting_key_absent",
   "message":"Tool result could not be submitted. The request may have expired or the connection was interrupted."}

So on macOS the dispatch happens but the result-submission side-channel is broken; on your Windows machines dispatch never starts. Both fit your "startup-fetched server-side change" hypothesis better than a client regression — my failures also survived a client update. Request IDs for backend tracing are in #79933.

[jbaconsult]

Corroborating from macOS 26.5.1 (Apple Silicon), Claude Desktop 1.24012.0 — same incident, with stdio-level captures that confirm the dispatch never happens.

Setup: local stdio MCP server (fork of @modelcontextprotocol/server-filesystem 2026.7.10) configured via claude_desktop_config.json. To rule the server out, I wrapped it in a tee interceptor that logs everything Claude Desktop writes to the server's stdin.

What the interceptor shows, for every one of 8+ server spawns since onset: both spawned instances (clientInfo claude-ai/0.1.0 and local-agent-mode-<server>/1.0.0) receive exactly initialize → notifications/initialized → tools/list and then nothing, ever. Verbatim capture of a session in which three tool calls failed in the UI (stdin, complete — nothing truncated):

{"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{"extensions":{"io.modelcontextprotocol/ui":{"mimeTypes":["text/html;profile=mcp-app"]}}},"clientInfo":{"name":"claude-ai","version":"0.1.0"}},"jsonrpc":"2.0","id":0}
{"jsonrpc":"2.0","method":"notifications/initialized"}
{"method":"tools/list","params":{},"jsonrpc":"2.0","id":1}

Server side (stderr) confirms it is up and configured, and answers both requests in <10 ms:

[mcp-fs 2026-07-21T20:22:53.372Z] Debug logging enabled via MCP_FS_DEBUG
Secure MCP Filesystem Server running on stdio
[mcp-fs 2026-07-21T20:22:53.374Z] Allowed directories at startup: ["/Users/<redacted>/dir-a","/Users/<redacted>/dir-b"]

Meanwhile the UI shows "Failed to call tool …" / "Tool execution failed" immediately after the permission prompt. claude.ai-web.log logs the tool_approval_gate with the correct <server>:<tool> name, then the call vanishes silently — no error in main.log, mcp.log, or the per-server log.

Timeline (UTC): first failing calls in my logs at 19:09 on 2026-07-21; sessions earlier that evening were already broken from ~18:1x–19:00. Consistent with your ~18:29 onset for freshly started instances.

Ruled out (failure survives all of the following, applied together): full macOS reboot; complete deletion of ~/Library/Application Support/Claude; sign-out and fresh sign-in; minimal fresh config; new conversations; server rename. Also reproduced with the official Filesystem connector — identical symptom.

Controls matching yours: remote connectors work in the same failing sessions; Claude Code (2.1.x) on the same machine, same account, dispatches tools/call to the same server binary normally.

One more data point that may help locate it: main.log shows the local tools are announced and the device bridge is healthy at the time of failure —

[localMcpBridge] announcing <server>: 14 tool(s)
[remote-tools-device] connecting DO bridge with: ... (+5 grand-prix, +45 local-mcp)
[remote-tools-device] authenticated

so the break appears to be between chat-side tool invocation and the local dispatch, not in server registration.

[ZachDreamZ]

I built a free tool that might help debug this — MCP Debug Proxy (github.com/ZachDreamZ/mcp-debug-proxy). It sits between Claude Desktop and any stdio-based MCP server to capture the full JSON-RPC exchange with microsecond timing.

In situations like this where ools/call sends but the response gets lost (the 404 side_channel pattern we're seeing in #79933), you can run:

�ash pip install mcp-debug-proxy mcp-debug --out session.json -- python your_server.py

This produces a full session log and latency report showing exactly where the round-trip fails — whether it's a missing response, a connection reset, or a timeout. I've been using it to characterize this exact bug pattern and the output helped narrow it to a client-side delivery issue rather than the server.

The CLI is MIT licensed on GitHub — no affiliation with Anthropic, just a tool I made while debugging my own MCP integrations.

Hope this helps folks triage while the root cause gets fixed.

[xenaocx-dev]

Corroborating from macOS 26.5 (Darwin 25.5.0, Apple Silicon), Claude Desktop 1.24012.0 — same incident, plus one additional control not yet in this thread.

Setup: two local stdio servers in claude_desktop_config.json, launched via npx: obsidian-mcp-server@3.2.9 and @modelcontextprotocol/server-filesystem.

Symptom (matches OP exactly): mcp-server-*.log shows both servers complete initialize + tools/list normally on every spawn, but zero tools/call entries ever appear; chat surfaces bare "Tool execution failed" (or hangs ~4 min). No error in main.log / claude.ai-web.log — the dispatch dies silently client-side.

Timeline (UTC): last successful chat tools/call batch logged 2026-07-19 ~14:24 (28 calls, zero errors). First failing instance started 2026-07-21 21:21 — after the ~18:29 threshold reported by OP. Consistent with a startup-fetched server-side change rather than the app binary (our auto-update installed hours before the onset and sessions kept working until relaunch).

Ruled out: fresh conversations; full Cmd+Q relaunches; renaming the server key in config (full client-side state/approval reset); re-pinning server versions; adding a brand-new never-before-seen filesystem server — it fails identically on first use.

Controls: (1) Claude Code sessions on the same machine, same account, same config, same server entries dispatch tools/call to both servers instantly, at the same moment chat fails. (2) A third-party agent connected to the same Obsidian instance via the plugin's built-in HTTP MCP endpoint works normally — only Desktop chat's local stdio dispatch path is affected.

[kstewart-bot]

Confirmation on two more Windows 11 machines — package family Claude_pzs8sxrjxfjjc

Reproduced on two additional Windows 11 machines (same sideloaded MSIX, package
family Claude_pzs8sxrjxfjjc). The log-level detail below is from the machine I
inspected directly; the second reproduced the same behavior end-user-side.

Symptom matches exactly: the bundled Filesystem extension (local stdio) completes
initialize and tools/list, then receives zero tools/call —
mcp-server-filesystem.log shows the request never arrives on stdin. Chat surfaces
"Failed to call tool list_allowed_directories" — a no-argument call, so path/scope
is not a factor. main.log logs no routing error, so the call dies in the
Chat/renderer layer before reaching the local bridge.

Consistent with the ~18:29 UTC server-side cutoff:

• Last successful tools/call on the inspected machine: 2026-07-21T19:32:20Z,
  on an app instance that had been running since before the cutoff.
• First relaunch after that (into 1.24012.0, ~19:58 UTC) → broken, and broken on
  every launch since.

Client version is not the differentiator (matches the report):

• Inspected machine: broke crossing 1.22209.0 → 1.24012.0; still broken on 1.24012.1.
• Second machine: was already on 1.24012.0 and working, then broke. A full
  shutdown/restart and installing the pending update did not restore it.

New datapoint — propagation to live sessions: on the second machine, an
already-running Chat session that had been working stopped working mid-session,
with no restart. So the change now affects in-flight sessions, not only instances
launched after the cutoff — keeping a pre-cutoff instance alive no longer helps.

Controls match: CoWork / Claude Code dispatches tools/call normally on both
machines (same account, same server binaries), and remote connectors are
unaffected. The failure is scoped precisely to Home/Chat → local stdio MCP servers.

[xenaocx-dev]

Update: auto-updated to 1.24012.1 (macOS, Apple Silicon) — still reproduces. Fresh conversation, freshly renamed server entries (clean approval state): both obsidian-mcp-server@3.2.9 and @modelcontextprotocol/server-filesystem fail with "Tool execution failed". tools/list handshake succeeds; no tools/call ever reaches either server process; no client-side error logged. Claude Code sessions on the same machine keep working against the same servers throughout. Consistent with a server-side gate rather than the app binary.

[jieuneun1999]

Confirming that it is happening to me as well

[BUG] Claude Desktop Windows MSIX 1.24012.1.0 — tools/call never dispatched for any MCP server (official extension + custom mcpServers both broken)

Environment

Claude Desktop version: 1.24012.1.0 (MSIX, Claude_pzs8sxrjxfjjc)
OS: Windows 10
Confirmed latest version via winget upgrade Anthropic.Claude → "No available upgrade found"

Bug Description

tools/call is never dispatched to any MCP server. Both the official Filesystem Desktop Extension and custom mcpServers entries complete the handshake and respond to tools/list, but no tools/call message is ever sent by the Claude Desktop client.

What works

MCP server starts and connects successfully
initialize → result completes
notifications/initialized sent
tools/list → result completes

What doesn't work

tools/call is never sent after any of the above

mcp.log evidence

2026-07-22T02:11:30.833Z [info] [filesystemfinal] Message from server: id=0 result
2026-07-22T02:11:31.335Z [info] [filesystemfinal] Message from client: method="notifications/initialized"
2026-07-22T02:11:31.346Z [info] [filesystemfinal] Message from client: method="tools/list" id=1 params
2026-07-22T02:11:31.354Z [info] [filesystemfinal] Message from server: id=1 result

No tools/call entry ever appears regardless of how many tool calls are attempted.

main.log evidence

For every custom mcpServers entry regardless of name:

[warn] UtilityProcess Check: Extension [server-name] not found in installed extensions

For the official Filesystem extension:

[info] Using UtilityProcess for extension Filesystem: appConfig.isUsingBuiltInNodeForMcp is true and built-in node is compatible

Both paths result in the same failure — tools/call never dispatched.

Official Filesystem Extension — allowlistEnabled bug

The official extension has a secondary bug: allowlistEnabled resets to false on every startup regardless of UI configuration.

config.json after every startup:

json
"dxt:allowlistEnabled:199b4c8d-63b1-49c8-a130-71c88b08a28b": false

Extension settings file (ant.dir.ant.anthropic.filesystem.json) correctly shows:

json
{
"isEnabled": true,
"userConfig": {
"allowed_directories": ["C:\Users\Papa\Desktop\Knowledgebase"]
}
}

The directory is saved correctly but the allowlist gate never activates. Manually flipping to true via PowerShell has no effect — Claude Desktop overwrites it back to false on the next startup, and does not re-read it mid-session.

Reproduction steps

Install Claude Desktop 1.24012.1.0 on Windows 11 via winget/Store (MSIX build)
Install the official Filesystem extension from Connectors panel
Add any allowed directory
Ask Claude to list that directory
Observe: tools/call never appears in mcp.log

Alternative reproduction:

Add any custom mcpServers entry to the MSIX config at %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json
Restart Claude Desktop
Ask Claude to use any tool from that server
Observe: same result — tools/call never dispatched, main.log shows UtilityProcess warning

Workarounds attempted — all failed

npx command → stdio pipe failure
node directly with absolute path → tools/call still not dispatched
Renaming server to avoid name collision with extension → same UtilityProcess warning, same failure
Manual config.json edit while Claude is running → ignored
winget upgrade → already on latest

Expected: tools/call dispatched after successful tools/list

Actual: Client goes silent after tools/list. No calls ever reach the server.

[jbaconsult]

Likely root cause found: tool-name mismatch between declaration and invocation for local MCP tools (DevTools/HAR capture of a failing turn, macOS, Claude Desktop 1.24012.0)

I captured a failing conversation turn in DevTools and the HAR shows the full round trip. Three steps, one tool_use_id:

1) The client declares local MCP tools to the backend by their bare name — completion request, tools array:

{"name":"list_allowed_directories","integration_name":"workspace","is_mcp_app":false}

(No mcp_server_url, no backend_execution — unlike remote connectors, which carry "backend_execution":true.)

2) The backend/model invokes them with a colon-qualified name — completion SSE stream:

{"type":"tool_use","id":"toolu_01UCTH2gdZiS856ciKfwKDCa",
 "name":"workspace:list_allowed_directories","integration_name":"workspace", ...}

3) ~4 s later the client posts the generic failure — same tool_use_id, POST .../tool_result:

{"type":"tool_result","tool_use_id":"toolu_01UCTH2gdZiS856ciKfwKDCa",
 "is_error":true,"content":[{"type":"text","text":"Tool execution failed"}]}

During that window my stdio interceptor confirms nothing is written to the local server's stdin — the renderer apparently fails to resolve the qualified name workspace:list_allowed_directories against its locally registered bare name list_allowed_directories and gives up before any dispatch.

This one mismatch explains every observation in this thread:

• Instant generic failure with zero local logs — the lookup fails before any IPC/stdio happens.
• Remote connectors unaffected — they are executed backend-side (backend_execution: true), where the qualified mapping is known.
• Onset ~18:29 UTC 2026-07-21 without any client update — consistent with a server-side rollout that started qualifying local-MCP tool_use names in the tool-search path.
• 1.24012.1 not fixing it — the client-side dispatcher was never taught to resolve <integration_name>:<tool>.

Suggested fix directions: strip/resolve the <integration_name>: prefix in the desktop client's local tool dispatcher, or roll back/gate the backend change that emits qualified names for locally executed tools.

I have also filed this through official support with the full (sanitized) HAR and log bundle, so engineering can request the complete captures there.

[fpl9000]

See #79992 (comment) for a workaround.

[jbaconsult]

macOS confirmation of the $schema workaround from #79992 (comment) — and a correction of my earlier root-cause hypothesis.

I inserted a transparent stdio filter in front of my filesystem server (fork of @modelcontextprotocol/server-filesystem, 14 tools, all declaring "$schema": "http://json-schema.org/draft-07/schema#" in inputSchema/outputSchema) that removes only the $schema keys from tools/list responses. Result on macOS 26.5.1, Claude Desktop 1.24012.1:

• Filter log: [strip-schema] removed $schema from 28 schema(s) (14 tools × input+output schema)
• The very next Desktop session dispatched the first tools/call since onset — captured on the server's stdin:
  {"method":"tools/call","params":{"name":"list_allowed_directories","arguments":{}},"jsonrpc":"2.0","id":2}
• Both calls returned normally in chat; ~10 prior sessions (2026-07-21/22, same machine, same app build) had shown handshake-only with zero tools/call.

Caveat: not a strict A/B on my side (I have not yet re-removed the filter), but combined with fpl9000's same-session A/B on Windows this looks conclusive.

Correction: in my earlier comment (#79926 (comment)) I hypothesized the colon-qualified tool_use names (<integration>:<tool>) were the root cause. That was observational correlation — the qualified naming is apparently normal and resolvable; the actual discriminator is the declared JSON-Schema meta-schema, consistent with a pre-dispatch tool-definition validator rejecting draft-07 $schema declarations before anything is serialized to the transport (which is why nothing is ever logged locally).

Workaround for anyone affected until Anthropic ships a fix: wrap your server command in a filter that strips $schema from tools/list responses (fpl9000's proxy, or a ~30-line Python line filter does it).