[BUG] Claude Desktop filesystem MCP — tool calls fail with empty server logs despite server running normally

Seeing the same failure mode on macOS with a different MCP server and transport, which rules out anything server-, OS-, or config-specific.

Setup

• Claude Desktop 1.24012.1 (macOS 14.4)
• was working fine up until the update to 1.24012.1
• Custom MCP server exposed over Streamable HTTP, bridged to stdio via supergateway --streamableHttp
• Client negotiates protocolVersion: 2025-11-25, clientInfo: { name: "claude-ai", version: "0.1.0" }

Symptom (identical): initialize and tools/list succeed and all tools show up; every tools/call fails instantly with Failed to call tool "<name>" / Tool execution failed, and the MCP server sees no tool call at all.

Where it actually breaks: The call is never dispatched by the client. In the gateway log, only initialize and tools/list are ever forwarded — there is no tools/call on the wire:

Stdio → Streamable HTTP: { id: 0, method: 'initialize', ... }
Streamable HTTP → Stdio: { method: 'notifications/initialized' }
Stdio → Streamable HTTP: { id: 1, method: 'tools/list', params: {} }
Response: { id: 1, result: { tools: [ ... ] } }
… then silence; no tools/call is ever sent …
Client transport closed (renderer released port)

The app does reach its internal approval gate ([MCP] tool_approval_gate { approvalRequired: true, hasBufferedInput: true }) and records the approval, but nothing is sent to the transport afterwards.

Independently verified the server + transport are healthy: driving the exact same endpoint through supergateway by hand — with the same protocolVersion (2025-11-25), clientInfo, and capabilities the app sends — returns a correct tools/call result. Postman and a direct Streamable-HTTP MCP client also work. So the server and bridge are fine; only the Desktop app fails to emit the call.

Ruled out:

• Tool permissions — fails with "Always Allow" set at both org and tool level.
• Org policy / admin allowlist — reproduced on a separate Free account with no policy at all, same machine.

Repro:

1. Add any MCP connector to Claude Desktop 1.24012.1.
2. Confirm it connects and lists its tools.
3. Ask for something that triggers a tool call.
4. Tool call fails immediately; the MCP server logs show no incoming call.

Happy to provide full logs / request IDs if useful.

Same issue — additional diagnostic detail that narrows where the failure occurs.

Broke immediately after this morning's (2026-07-22) auto-update on the Windows MSIX/Store build (package family Claude_pzs8sxrjxfjjc). Worked normally before the update. Windows 11, filesystem MCP server (@modelcontextprotocol/server-filesystem via npx), config verified correct at the virtualized path (%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json).

Key finding: tool calls reach the renderer's approval gate, pass it, and never arrive at the MCP client.

1. Server is healthy — manual spawn in PowerShell starts clean ("Secure MCP Filesystem Server running on stdio").

2. App-to-server connection is healthy — mcp.log and mcp-server-filesystem.log show a successful initialize handshake and tools/list response on every app launch. Allowed directories load correctly.

3. The break is between renderer and MCP client. claude.ai-web.log logs every failed call at the gate, e.g.:

10:13:37 [warn] [MCP] tool_approval_gate {"toolId":"toolu_013wdCG8CXpDNSW2LGBjawEs","toolName":"filesystem:list_directory","approvalRequired":false,"hasBufferedInput":false}

That call — and every other tools/call today — never appears in mcp.log (startup handshake only, all day). main.log shows no errors at failure times. No error is logged anywhere between gate and MCP client. This matches the OP's "empty server logs despite server running normally" — the calls are dying in the app's renderer-to-main-process hop before the MCP layer ever sees them.

4. Possibly related: one call was gated approvalRequired:true, hasBufferedInput:true with no visible prompt and no logged resolution. Also a burst of [REACT_QUERY_CLIENT] "data is undefined" errors (account_profile, subscription_details, memory_settings) at sign-in.

Did not fix it: full quit/relaunch (multiple), sign out/in, new conversations, disabling Chrome extension, toggling the filesystem connector off/on (this made an approval prompt appear for the first time — set to always-allow — but calls still fail identically, including in fresh chats).

100% reproducible: any conversation → any MCP tool call → instant generic failure.

Existing issue on this case: #79992

Best analysis so far: https://github.com/anthropics/claude-code/issues/79992#issuecomment-5049455483
the "$schema" in tools/list output is confirmed for my mcp server as well.

Same:

Summary

Since the desktop auto-update installed Jul 21 ~8:58 PM ET, all tool calls to a
local MCP server whose tools are gated with approvalRequired: true fail with a
generic "Failed to call tool" toast. No approval prompt is ever rendered anywhere
in the UI. The tool call is held at the approval gate and never dispatched to the
MCP server. First-party connector tools marked approvalRequired: false
(claude-code) work normally in the same session.

Environment

• Claude Desktop macOS 1.24012.1 (fresh reinstall Jul 22; bug present before and after)
• macOS, Apple silicon MacBook Pro
• Node v22.14.0, npx 10.9.2
• Server: @modelcontextprotocol/server-filesystem (stdio), 6 allowed directories
• Two other local MCP servers in same config work fine: claude-code (claude mcp serve)

and a custom node git server

Smoking gun (renderer log, ~/Library/Logs/Claude/claude.ai-web.log)

Same session, minutes apart:

[MCP] tool_approval_gate {"toolName":"claude-code:Bash","approvalRequired":false,"hasBufferedInput":false} → succeeds
[MCP] tool_approval_gate {"toolName":"claude-code:Read","approvalRequired":false,"hasBufferedInput":false} → succeeds
[MCP] tool_approval_gate {"toolName":"fs-mcp:list_allowed_directories","approvalRequired":true,"hasBufferedInput":true} → fails, no prompt shown
[MCP] tool_approval_gate {"toolName":"fs-mcp:list_directory","approvalRequired":true,"hasBufferedInput":true} → fails, no prompt shown

Server-side log (mcp-server-filesystem.log) confirms the server initializes,
completes the handshake, and answers tools/list — but zero tools/call messages
ever arrive. mcp.log shows the same: claude-code tools/call entries flow
normally; none for filesystem.

Timeline (ET)

• Jul 14–21: filesystem MCP worked extensively (daily use, reads/writes/edits)
• Jul 21 4:39 PM: last successful filesystem tools/call in logs
• Jul 21 8:58 PM: ShipIt auto-update installs and relaunches app

(ShipItState.plist + ShipIt_stderr.log timestamps: 20:58:04–20:58:15)

• Jul 21 ~9:45 PM: first confirmed failures; every filesystem call since fails identically

Ruled out by testing

• Config syntax (validates clean; two sibling servers in same file work)
• Server name collision (renamed "filesystem" → "fs-mcp": identical failure)
• npx indirection (invoked dist/index.js via node directly: identical failure)
• stdout protocol pollution (banner confirmed on stderr; stdout clean)
• Stale app/local state (full uninstall incl. Application Support, Caches,

Preferences, saved state; fresh install; config restored: identical failure —
so this is default-state behavior, not corruption)

• Server health (standalone launch clean; handshake and tools/list always succeed)

Expected

Either an approval prompt is displayed when approvalRequired=true, or the tool
call proceeds.

Actual

No prompt anywhere; call dies at the gate; user sees only "Failed to call tool."

Possibly related

A chat started on mobile during the same window was silently overwritten/reverted
by desktop state on next desktop launch — may share a root cause in the update's
session/sync handling.