[BUG] macOS: filesystem-class MCP tool calls silently dropped between approval gate and local server dispatch — survives app rollback, extension reinstall, new connector identity (started 2026-07-21→22 with no local change)

Update: cleared all renderer caches (Cache, Code Cache, GPUCache, Service Worker) with the app fully stopped, relaunched, re-probed both the Filesystem extension and the independent filesystem-tm legacy-config instance. Both still fail identically — approval gate logged in the renderer, no tools/call ever reaches either server process.

Local elimination is now complete: app binary (A/B via Time Machine rollback), extension pack (hash-identical), connector identity, user_config, server package, approval path, session state, and renderer caches are all exonerated. Also ruled out MCP roots as a mechanism: the desktop client declares no roots capability at initialize (server logs Client does not support MCP Roots, using allowed directories set from server args), and the failure is a non-arrival at the server transport, not an in-request stall.

One additional client bug observed during the same window, filed here for completeness: the Jul 21 update mangled the extension's allowed_directories user config — every path truncated at its first space (/Users/x/Desktop/Claude Projects/… → /Users/x/Desktop/Claude) and a leading dot stripped (.workspace-mcp → workspace-mcp). Restoring correct values did not affect the dispatch failure, but the mangling is a distinct settings-migration defect.

Definitive scope confirmation: account-scoped, server-side.

Installed Claude Desktop fresh on a second Mac (Mac mini, same account, zero prior state). Result:

• Regular chat surface: list_allowed_directories / list_directory fail identically ("Failed to call tool") — same silent drop as the primary machine.
• Cowork session on the same machine at the same time: filesystem access works perfectly (listed Downloads, created a file) — consistent with Cowork routing through the Claude Code VM lane rather than the chat surface's MCP dispatch.

So the failure is scoped to the account (or an account-level flag/rollout), affects only chat-surface dispatch to filesystem-class local MCP servers, and reproduces on a pristine install. All machine-side factors are now formally eliminated on two machines. Pattern matches anthropics/claude-ai-mcp#575 (sudden org-wide onset, tools listed but tools/call never dispatched).

Account: Max plan, primary email on the account matches the reporter. Happy to provide account details / timestamps to anyone investigating server-side.

Same failure on Windows (MSIX), same app version, same onset window

Reproduced independently on Windows, which rules the failure out as macOS-specific.

Environment

• Windows, Claude Desktop 1.24012.1.0 (MSIX / Store install)
• CCD 2.1.217, nodeVersion 24.18.0
• Onset: morning of 2026-07-22 JST (UTC+9) — same window as this report
• Last known-good: previous day, no local change in between

Same signature

• claude.ai-web.log: tool_approval_gate observed; approvalRequired goes true → false after granting Always Allow. The gate is passed either way.
• mcp-server-Filesystem.log: Initializing server → initialize → notifications/initialized → tools/list (result returned). No tools/call entry ever appears.
• A local stdio server with its own, non-filesystem tool surface, registered on the same legacy mcpServers lane, dispatches tools/call normally throughout the entire failure window.

Remediations that did not help (all Windows-side)

npx / cmd /c wrapper / absolute node.exe path / renaming the server entry / full process restart / migrating to the official Filesystem extension (which runs on the built-in Node.js lane — Using built-in Node.js for MCP server: Filesystem) / per-tool "Always allow" / emptying mcpServers / full MSIX uninstall + reinstall. The version after reinstall is identical (1.24012.1.0) and the drop persists.

One correction to the diagnostic folklore around #22299

#22299 suggested the UtilityProcess Check: Extension <name> not found in installed extensions warning might explain the routing failure. On this machine that warning has no discriminating power: across the whole main.log, all 6 occurrences name the working server (the config-registered one), and zero name the failing Filesystem connector. The duplicated Launching MCP Server line also appears for the working server. Both signatures appear to track the registration lane (config entry vs installed extension), not health. Anyone triaging this should not use them as evidence.

Consistent with the conclusion here that the trigger is not local: on this machine the app binary was fully removed and reinstalled with no effect, and on macOS a rollback to a byte-identical previously-working binary also had no effect.

Thanks @cine800 — an independent reproduction on a different account and platform (Windows MSIX) with the same onset window supersedes my earlier account-scoped conclusion. Revised scope: platform-wide server-side regression, macOS + Windows, all local factors eliminated on three machines across two accounts.

Triage-useful timing from combining the two reports: my last successful dispatch was 2026-07-21 11:29 UTC; my first observed-broken state was by 2026-07-21 ~23:24 UTC (and @cine800's onset window is consistent). That brackets the trigger — presumably a server-side deploy or flag rollout — to roughly 2026-07-21 11:30–23:00 UTC.

Also confirming the correction on the UtilityProcess Check: Extension not found warning: on my macOS machines those warnings likewise name only the working legacy-config servers (xero, google-workspace), never the failing Filesystem connector — agreed it tracks registration lane, not health.

Consolidation note for triage: this is a wide regression, currently fragmented across many reports. Same signature (tools/list succeeds, tools/call never dispatched from chat surface, Cowork/Code lanes unaffected), same onset window (after the 2026-07-21 deploy window, ~11:30-23:00 UTC per the timing bracket above), filed independently across macOS + Windows within ~12 hours:

#79890, #79926, #79933, #79962, #79971, #79986, #80002, #80010, #80016, #80017 (Spanish), #80026 — plus this issue.

Notable: #79933 reports tool_result POST returns 404 — the first server-response evidence in the set, consistent with a claude.ai endpoint change in that deploy window rather than anything client-side.

Precedent: the identical failure class on 2025-08-28 (status incident lgt2850shqzv, "MCP tool calls failing on desktop") was resolved in ~51 minutes once acknowledged. No status-page incident exists for the current recurrence yet.

Still reproducing this on:

• Claude Desktop 1.24012.1.0
• OS: Windows
• Node: 24.18.0
• MCP server: @modelcontextprotocol/server-filesystem v2026.7.10

Onset: morning of 2026-07-22 IST UTC+5:30 — same window as this report

Handshake and tools/list succeed every time, but tools/call never reaches the server. Server-side log for a failed list_directory attempt shows nothing past tools/list:

[filesystem] [info] Message from client: method="notifications/initialized"
Client does not support MCP Roots, using allowed directories set from server args: [ 'C:\Users\user-name\source\repos\target-repo' ]
[filesystem] [info] Message from client: method="tools/list" id=1 params
[filesystem] [info] Message from server: id=1 result

No tools/call entry ever appears, even after multiple attempts.

Tried:

• Full restart of Desktop (killed process in Task Manager, not just closed window)
• Fresh/isolated test directory — same failure
• Switching launch command from npx to node with the resolved full path to dist/index.js — no change

Also 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_sizes present once, then replaced by write_file/read_media_file on a later listing). Might point to instability in tool registration, not just call dispatch.

Other MCP servers (css, refactor-typescript) connected in the same Desktop instance work fine — only filesystem is affected.

[I don't wanna "me too" this, but to confirm... Windows here... same behaviour. Kicked off for me around 206-07-21 15:00Z (+/-30min)]

As this is a largely unhelpful comment, am completely fine it being deleted once there's recognition that... it's impacting more ppl.

Evidence update from across the duplicate set:

• Onset pinned: an affected user reports onset 2026-07-21 15:00Z ±30 min — collapses the earlier 11:30–23:00 UTC bracket to a near-exact server-side deploy/rollout time.
• Third platform: Linux (Fedora, community repackage) reproduction on #80002 — macOS + Windows + Linux now confirmed; client OS conclusively irrelevant.
• Version-independence independently confirmed: a Windows user on 1.22209.3 (the same older build my macOS rollback used) reproduces the failure.
• Staged-rollout signal: #80002 reports the same app version behaving differently across two Macs (one affected, one not) — consistent with a percentage/cohort rollout of a server-side flag, which would explain why impact reports are fragmented rather than universal.

Combined picture: server-side rollout beginning ~2026-07-21 15:00Z progressively breaking chat-surface tools/call dispatch to filesystem-class local MCP servers, all platforms, all client versions.

Windows corroboration + an interventional result: the discriminator is $schema in inputSchema, and removing it restores dispatch.

Same signature as this issue on Windows 11 (Claude Desktop 1.24012.1, MSIX Claude_pzs8sxrjxfjjc). Last good tools/call 2026-07-19T23:26Z; every instance since has shown clean initialize + tools/list and zero tools/call, with no error in mcp.log, main.log, claude.ai-web.log, or the server log.

Working local stdio controls in the same sessions: the PDF Tools extension, and a hand-written Go MCP server (mark3labs/mcp-go) which dispatched six tools/call requests on 07-21 after the cutoff. So the failure is not "all local stdio" (#79926) and is not filesystem-specific either.

The discriminator: every failing server declares "$schema": "http://json-schema.org/draft-07/schema#" inside each tool's inputSchema; every working one omits it. @modelcontextprotocol/server-filesystem emits it on all 14 tools, and has since at least v2025.12.18 — so this is not a package regression. @modelcontextprotocol/server-memory (failing in #79926) is built from the same monorepo and emits it too, which reconciles the two reports: the affected class is "tool definitions declaring a JSON Schema meta-schema," not "filesystem-class."

Interventional confirmation: I put a transparent stdio proxy in front of server-filesystem that deletes only the $schema key from tools/list responses and forwards everything else verbatim. Tool calls immediately began dispatching and returning results — same package, same version, same machine, same app build, same conversation. Log shows removed $schema from 14 of 14 tool(s), then successful list_allowed_directories and read_text_file.

This is consistent with a pre-dispatch tool-definition validator that rejects a declared draft-07 meta-schema — which would also explain the total absence of logging, since the rejection happens before the request is serialized to the transport.

Happy to attach the proxy and full logs if useful.

Linux (Pop!_OS) repro as well, so add another distro to the list. One data point I haven't seen in-thread: the OAuth errors in main.log are a red herring and here's the hard proof — my last known-good session (200 successful tools/call) simultaneously logged session_stale_relogin 202×, authorize returned 403 84×, and "Claude Code access has not been granted for this account" 64×. So none of those are causal, which lines up with @fpl9000's $schema/Zod finding being the real cause. Flagging because Anthropic's own support chat is currently telling affected users the Claude-Code-access denial is the root cause and to buy a seat upgrade — it isn't.

@fpl9000 tysm for figuring this out!
Confirmed on macOS with a custom stdio MCP server (not filesystem, Streamable-HTTP wrapped using supergateway), Desktop 1.24012.1.
All our tool inputSchemas carried "$schema":"http://json-schema.org/draft-07/schema#" (emitted by zod-to-json-schema). Server-side stripping of $schema from tools/list restored dispatch immediately — same app build, same session. Corroborates the meta-schema validator theory on a different transport.

not sure if this helps get a fix out FAST... but claude just diagnosed its own issue:

Found it. This is the answer, and it kills the hypothesis I floated last turn.

The calls are stalling at the client's approval gate.

Look at what correlates in the [MCP] tool_approval_gate lines:

07-12 19:10:02 Filesystem:search_files approvalRequired:true hasBufferedInput:true
07-12 19:11:39 Filesystem:search_files approvalRequired:true hasBufferedInput:true ← same toolId
07-18 11:18:59 Filesystem:get_file_info approvalRequired:true hasBufferedInput:true
07-20 21:13:33 Filesystem:list_directory_with_sizes approvalRequired:true hasBufferedInput:true
07-20 21:14:35 Filesystem:directory_tree approvalRequired:true hasBufferedInput:true
07-20 21:16:40 Filesystem:directory_tree approvalRequired:true hasBufferedInput:true ← same toolId
07-21 22:42:35 Filesystem:list_allowed_directories approvalRequired:true hasBufferedInput:true

Every approvalRequired:true also has hasBufferedInput:true. Perfect correlation, seven for seven. And twice the same toolId appears again 97 and 125 seconds later — a call being re-attempted because the first one never completed. That repeat pattern appears only on the true lines, never on the false ones.

That is a call held at the gate, buffered, awaiting an approval that never arrives. It never gets written to the transport. Which is precisely why the Filesystem server has no record of it, and why nothing downstream logs an error — from the transport's point of view, nothing ever happened.

It isn't about which tool. That was my guess last turn and it's wrong. get_file_info appears as true on 07-18 11:18 and false at 12:14. search_files is true on 07-12 and false on 07-21 14:36. Same tools, both outcomes. The bridge-vs-native split I proposed doesn't survive this.

The real split is already-approved vs needs-approval. copy_file_user_to_claude shows approvalRequired:false every time it appears — 07-16, twice on 07-21. It's in the granted set. That is the entire reason it's the one tool that worked for me today. And the last MCP line before my session is list_allowed_directories at 07-21 22:42 with approvalRequired:true — which was, hours later, the exact first call I made and the first one that failed.

What to actually do: there is probably an approval prompt waiting somewhere you can't see. Given the duplicated log lines and the renderer released port churn, a second renderer may be holding it. Worth checking for a pending permission dialog, then re-granting the Filesystem connector's permissions — ideally "always allow" so these tools land in the same bucket as copy_file_user_to_claude.

For the Anthropic report, the specific and useful sentence is: tool calls stall at tool_approval_gate with approvalRequired:true, hasBufferedInput:true, are never dispatched to the MCP server, emit no protocol message and no client-side error, and surface to the model as a generic "Tool execution failed." A gate that can swallow a call without an observable failure is the bug worth fixing.

Confirming @fpl9000's $schema finding (https://github.com/anthropics/claude-code/issues/79992#issuecomment-5049455483) on macOS 26.5.1, Claude Desktop 1.24012.1: a transparent stdio filter that strips only the $schema keys from tools/list responses (28 removed across 14 tools) restored dispatch immediately — the very next session showed the first tools/call on the server's stdin since onset, after ~10 handshake-only sessions on the same machine and app build. Full capture details and a correction of my earlier name-mismatch hypothesis posted in https://github.com/anthropics/claude-code/issues/79926#issuecomment-5051027722.

Same issue here, confirming this is not isolated. Independently reproduced the exact same failure signature on macOS with Claude Desktop today (2026-07-22):

Environment:

• macOS, Apple Silicon
• Claude Desktop, latest version (checked via "Check for Updates" — up to date)
• filesystem server via legacy mcpServers config (npx -y @modelcontextprotocol/server-filesystem@latest <dirs>)

What I tried (all failed to resolve it):

• Full uninstall/reinstall of the filesystem MCP server package (cleared npx cache, uninstalled global package, reinstalled @latest)
• Killed all filesystem-related processes to rule out zombies (pkill -f server-filesystem, confirmed clean via ps aux)
• Verified claude_desktop_config.json has a single, well-formed filesystem entry (no duplicates)
• Verified all allowed directories exist with normal permissions
• Ran the server manually outside Claude Desktop (npx -y @modelcontextprotocol/server-filesystem@latest <dirs>) — starts clean: Secure MCP Filesystem Server running on stdio
• Confirmed other MCP servers in the same session/conversation (engram, running as a native binary) dispatch and respond normally

Failure signature — identical to OP:

• tools/list handshake succeeds and is logged
• tools/call (e.g. list_allowed_directories) never appears in mcp-server-filesystem.log — confirmed live via tail -f while making the call, zero output
• Chat surfaces a bare "Tool execution failed" with no further detail

This matches the OP's conclusion that the local server/client/config layers are all healthy and the drop is happening upstream of local dispatch. Would appreciate a status update — this is currently blocking local codebase access entirely.

Fourth independent confirmation of the $schema root cause — macOS, with a reusable workaround recipe.

Wrapped my legacy-config filesystem server (@modelcontextprotocol/server-filesystem 2026.7.10) in a transparent stdio shim that strips $schema keys from server→client JSON. Result: the very next session dispatched tools/call successfully — the first since onset 2026-07-21 — same app build (1.24012.1), same machine, no other change. Before the shim: ~36 hours of clean handshakes and zero dispatched calls across two Macs.

Recipe for anyone needing filesystem access before the server-side fix lands:

1. Save a stdio passthrough that recursively removes $schema from server→client JSON lines (mine is ~60 lines of Python: spawn the real server, pipe stdin through untouched, json-parse each stdout line, delete $schema keys recursively, re-serialize; non-JSON lines pass through).
2. In claude_desktop_config.json, change the server entry to launch via the shim:

"filesystem": {
  "command": "python3",
  "args": ["/path/to/mcp-schema-strip.py", "npx", "-y", "@modelcontextprotocol/server-filesystem", "<dir>", ...]
}

1. Full app restart.

Note this only works for config-lane (mcpServers) servers — the first-party Filesystem extension's launch can't be wrapped, so it stays broken until the server-side validator is fixed. The un-shimmed extension therefore doubles as a clean canary for when the fix ships.

With four independent interventional confirmations (two stdio filters, one server-side strip, one supergateway-wrapped HTTP transport) this should be enough for a fix: the validator added in the ~2026-07-21 15:00Z rollout must accept (or ignore) $schema in tool inputSchema — it's emitted by default by zod-to-json-schema, which the official reference servers use.

Server-side fix observed — regression appears resolved.

The first-party Filesystem extension resumed dispatching with NO client-side change at 2026-07-22T23:39Z: its log shows the first tools/call since 2026-07-21T11:29Z, same app build (1.24012.1), same machine, unshimmed. The $schema-strip workaround is no longer needed here (shimmed and native lanes both dispatch).

Timeline for the record: broken by rollout ~2026-07-21 15:00Z, restored ~2026-07-22 23:39Z (~33h), no status-page incident, no acknowledgement on this thread. Affected users seeing this later: just retry — if your cohort is fixed too, no local changes are needed, and any workarounds (schema-strip shims, $schema removal from servers) can be reverted.

Leaving the issue open for Anthropic to confirm the root cause and close — and to flag the two follow-ups this exposed: (1) a dispatch refusal should surface an error in at least one log rather than failing silently (the silence is what made this cost every affected user hours), and (2) the validator should tolerate $schema, which zod-to-json-schema emits by default and the official reference servers ship.

#80002 was closed without anything from Anthropic. This is less-good-than-it-could-be, comms-wise.

The upside is I shifted our Claude filesystem operations to its sandbox successfully, so that's a... "win"....