[BUG] MCP Tools usage
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?
Title: [BUG] Claude Desktop 1.24012.1 (macOS): all local MCP tool calls fail — approval gate fires, tools/call never reaches servers
Version: 1.24012.1 (0adcae), built 2026-07-21T20:59:53Z, macOS (Apple Silicon)
Timeline: Local MCP worked for weeks. At 2026-07-22 01:55:41 UTC all three MCP child processes were killed un-gracefully (mcp-server logs: "Server transport closed unexpectedly... process exiting early") — consistent with the auto-updater installing this build, compiled ~3h earlier. All MCP tool execution broken since.
Symptoms:
- Every tool call from every conversation fails with a generic error
- Servers are healthy: initialize / notifications/initialized / tools/list all succeed on every app launch; tool schemas appear in conversations
- mcp-server-*.log contains ZERO
tools/callentries — calls never reach the servers - claude.ai-web.log shows
[MCP] tool_approval_gatefiring per call (approvalRequired:false, hasBufferedInput:false) with no subsequent forward to the server - Followed by:
[REACT_QUERY_CLIENT]404not_found_error/side_channel_waiting_key_absenton POST/chat_conversations/{id}/tool_result— "Tool result could not be submitted. The request may have expired"
Ruled out: valid config (3x official mcp-server-filesystem, absolute paths), multiple full Cmd+Q restarts, complete delete + fresh reinstall from claude.ai/download, 6+ brand-new conversations, different servers. All fail identically.
Likely related: #22451 (all MCP calls hang ~5 min then "No result received from client-side tool execution")
What Should Happen?
Tools should work fine
Error Messages/Logs
Steps to Reproduce
Steps to Reproduce:
- macOS, Claude Desktop 1.24012.1 (0adcae). Configure one or more local stdio MCP servers in
claude_desktop_config.json— e.g. the official filesystem server:
{
"mcpServers": {
"regalcare": {
"command": "/Users/<user>/.nvm/versions/node/v22.17.1/bin/mcp-server-filesystem",
"args": ["/Users/<user>/Documents/GitHub/<repo>"]
}
}
}
- Launch Claude Desktop. Server starts and handshakes successfully — Settings shows "running", and
~/Library/Logs/Claude/mcp-server-*.logshowsinitialize,notifications/initialized, andtools/listall completing. - Open any conversation (new or existing) and ask Claude to call any tool from the server, e.g.
list_allowed_directories(zero-argument, touches no path). - Observe: Claude receives a generic tool execution failure.
Expected: Tool call is forwarded to the MCP server over stdio and returns a result, as in all prior versions.
Actual:
claude.ai-web.loglogs[MCP] tool_approval_gatefor the call (approvalRequired:false) — the call reaches the app- The server log shows no
tools/callentry — the app never forwards it (grep -c "tools/call" ~/Library/Logs/Claude/mcp-server-*.logreturns 0) claude.ai-web.logthen logs a 404not_found_error(side_channel_waiting_key_absent) on POST.../tool_result- Reproduces 100%: every tool, every server, every conversation, after full restarts and a clean reinstall
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Claude 1.24012.1 (0adcae) 2026-07-21T20:59:53.000Z
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
4 Comments
having this issue on Windows 10 as well, all was going fine, been using mcpserver local filesystem (Settings -> Developer -> Local MCP Server via Edit Config) for over a month just fine, then i saw an "Updating" in the bottom left corner of Claude Desktop (something i have NEVER seen before, because it always requires manual clicking) and then when i tried to have it access the mcp server for my project it would say errors for the tools in the top right corner, all tool commands would fail, but the mcp server looks like it's connected and etc. i have done NOTHING at all other than notice that weird "Updating" in the bottom left corner of claude desktop before it prompted me to update to the latest version. (I am using Claude Desktop on Windows 10 -> Chat -> Local Desktop (not beta cloud))
Still reproducing this on:
@modelcontextprotocol/server-filesystemv2026.7.10Onset: morning of 2026-07-22 IST UTC+5:30 — same window as this report
Handshake and
tools/listsucceed every time, buttools/callnever reaches the server. Server-side log for a failedlist_directoryattempt shows nothing pasttools/list:No
tools/callentry ever appears, even after multiple attempts.Tried:
npxtonodewith the resolved full path todist/index.js— no changeAlso noticed the exposed tool list itself is inconsistent across the same session — at one point no filesystem tools were listed at all ("Tool not found"), and a later retry exposed a different subset than before (e.g.
list_directory_with_sizespresent once, then replaced bywrite_file/read_media_fileon a later listing). Might point to instability in tool registration, not just call dispatch.Other MCP servers connected in the same Desktop instance work fine — only filesystem is affected.
Can confirm this also affects Windows (MSIX/Microsoft Store install), same exact version
1.24012.1 (0adcae), with a local stdio MCP server (Node.js, not the official filesystem server). Same signature:tools/listsucceeds every launch, buttools/callnever reaches the server — confirmed viagrep -c "tools/call"on the server's own log across 6 separate attempts, spanning a full companion-app restart, a connector toggle off/on, and a full Claude Desktop restart. 0 matches every time.Also ruled out on my end that it's server-side: bypassed the app entirely and hit the MCP server's own debug HTTP interface directly (
GET http://127.0.0.1:3000/health?deep=1), which returned a fully healthy response — confirming the server and its downstream connections work perfectly end-to-end. The failure is isolated to Claude Desktop's tool-call dispatch, matching your finding that the approval gate fires but the request is never forwarded.Given this reproduces identically on Windows and macOS with completely different MCP servers, this looks like a dispatch-layer regression in this specific build rather than a platform- or server-specific issue.
Quite possibly related to a workaround here.
https://github.com/modelcontextprotocol/servers/issues/4545#issuecomment-5056557933