[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

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.

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.

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.

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.

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.

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.

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.

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.

See https://github.com/anthropics/claude-code/issues/79992#issuecomment-5049455483 for a workaround.

macOS confirmation of the $schema workaround from https://github.com/anthropics/claude-code/issues/79992#issuecomment-5049455483 — 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 (https://github.com/anthropics/claude-code/issues/79926#issuecomment-5043423056) 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).