server-filesystem >=2025.11.25 (registerTool/outputSchema rewrite): 100% tool-call failure on Claude Desktop 1.24012.1 Windows — calls never dispatched to server

[sonofsmog]

Bug report: Filesystem extension v2026.7.10 — 100% tool-call failure on Claude Desktop 1.24012.1 (Windows)

Environment

• OS: Windows 11 Enterprise 10.0.26200
• Claude Desktop: 1.24012.1, Microsoft Store MSIX build (C:\Program Files\WindowsApps\Claude_1.24012.1.0_x64__pzs8sxrjxfjjc)
• Filesystem extension: ant.dir.ant.anthropic.filesystem v2026.7.10 (auto-updated 2026-07-21 ~16:56 local; previously working for months)
• System Node: v22.22.0 (also reproduces with the app's built-in Node / UtilityProcess mode)

Symptom

After the extension auto-updated to 2026.7.10, every Filesystem tool call in desktop chat fails with a bare "Tool execution failed" — including list_allowed_directories, which takes zero arguments. 100% failure rate, all 14 tools. No error detail surfaced anywhere.

Key evidence (from %APPDATA%\Claude\logs)

1. Calls never reach the server. mcp-server-Filesystem.log shows every session since the update doing a successful initialize + tools/list, then zero tools/call messages ever arriving. The last tools/call logged is from 2026-07-20, pre-update. The renderer logs the call at its approval gate (tool_approval_gate … Filesystem:list_directory), then dispatch fails client-side.

2. The server binary is healthy. Driving the exact installed dist/index.js manually over JSON-RPC (system Node v22, same args/allowed dirs) succeeds for every tool: initialize, tools/list, list_allowed_directories, list_directory, get_file_info, error cases — all correct.

3. Version boundary identified by inspecting npm tarballs:

   • @modelcontextprotocol/server-filesystem ≤ 2025.8.21 — old tools/list shape (no outputSchema) → works with this desktop build (verified by dist-swap: calls dispatch and succeed until the app's extension-integrity check reverts the swap)
   • ≥ 2025.11.25 — rewritten with registerTool + outputSchema/structuredContent on every tool → this desktop build refuses to dispatch any call to the server
   • MCP roots support (added 2025.7.29) is NOT the cause — it shipped in versions that worked for months.

4. Control case proving the bridge/dispatch path is fine: the Windows-MCP extension (registry-installed, old-style tool schema) lists AND executes tools in the same chat sessions without issue.

5. initialize latency regression: the v2026.7.10 server takes 8–13 s to answer initialize under the app (older versions: <1 s), which also trips the localMcpBridge startup path (ensureAllConfiguredConnected timed out after 10000ms → announcing partial/empty set).

Workarounds attempted — every alternative injection path is blocked by design

• claude_desktop_config.json mcpServers entry (pinned server 2025.8.21, system Node): server connects and serves tools/list, but its tools are never bridged into chat — connecting DO bridge with: … (+0 local-mcp).
• Local .mcpb extension (same pinned server, drag-installed, local.mcpb.* id): installs, launches, handshakes cleanly on every restart — localMcpBridge never announces it (only registry ant.dir.* extensions are announced).
• Swapping known-good dist/ into the registry extension: works (calls dispatch and succeed) until the next enable/disable cycle, when the app's integrity check silently removes the extension's tool registration; only a full UI reinstall restores it (which also restores the broken code).
• Net result: no user-side fix exists. The app's (reasonable) security model blocks every repair path.

Additional bridge fragility observed

• [localMcpBridge] no stdio servers connected is announced ~1 s after launch, racing server handshakes; recovery (late stdio connect after announce — reloading bridge) fires inconsistently.
• An enabled extension that can never launch (stale Windows-MCP entry) stalls ensureAllConfiguredConnected into a 10 s timeout and an empty announce.
• Editing extension settings/manifest files on disk desyncs the app's registration state from the settings JSON; the extension launches but its tools silently vanish from chat with no error.

Impact

Filesystem access — the primary reason to run Claude Desktop over the browser — is completely unusable. This is the second multi-day filesystem breakage on this machine. Current user workaround: routing all file operations through the third-party Windows-MCP extension.

Requests

1. Ship a desktop build that dispatches calls to servers using the current MCP SDK tool schema (outputSchema/structuredContent), or roll the bundled Filesystem extension back to the 2025.8.21 shape until the client is ready.
2. Integration-test the bundled extension against each supported desktop build before auto-updating it in place (note: MS Store builds lag, widening the skew window).
3. Surface dispatch failures with an actual error message instead of a bare "Tool execution failed".
4. When an extension's integrity/registration check fails, say so in the UI instead of silently dropping its tools.

[sonofsmog]

Cross-reference: independently reported against the client at anthropics/claude-code#79986 (different reporter, Windows 10, direct-download install — same build 1.24012.1, same extension, identical zero-dispatch signature). Additional evidence including the schema-version boundary and a two-machine matrix posted there.

[inddev]

Confirming on macOS, with a divergence from the Windows findings. Full writeup with logs and screenshots: anthropics/claude-code#80094

≥2025.11.25 (tested 2026.1.14 and 2026.7.10) via classic mcpServers config: matches your findings - clean initialize + tools/list, zero tools/call ever dispatched, bare "Tool execution failed". Two machines (Desktop 1.24012.0 / 1.22209.3, both macOS 26.5.2), broke in the 19–21 July auto-update window.

2025.8.21 diverges from your dist-swap result: the binary answers tools/list correctly over raw stdio, but Desktop registers the connector as "This connector has no tools available" - tools dropped at registration. So on macOS neither generation works via classic config.

Boundary-narrowing datapoint: a minimal custom SDK server using registerTool with inputSchema only - no outputSchema - dispatches and executes perfectly in the same session/turn on the same directory. Suggests the refusal keys on outputSchema/structuredContent specifically, not the registerTool rewrite as a whole.

[tobimax]

I fixed this using a workaround shim to sanitise the response from the MCP server. The root cause is the draft specification in the response header, which Claude Desktop has tightened causing it to error out or not even log it.

Claude Desktop Config MCP Servers (Windows)

"mcpServers": {
  "wsl-filesystem": {
    "command": "C:\\Windows\\System32\\wsl.exe",
    "args": [
      "--",
      "/home/MYHOMEFOLDER/REPO/.mcp/filesystem.sh"
    ]
  }
}

WSL MCP Server Entry Point

#!/bin/bash
# .mcp/filesystem.sh — filesystem MCP server, scoped to the repo root.
#
# Launched by Claude Desktop (see .mcp/README.md):
#   "filesystem": {
#     "command": "wsl.exe",
#     "args": ["--", "<REPO_ROOT>/.mcp/filesystem.sh"]
#   }
#
# Scope is the repo root, derived from this script's location. Claude cannot read
# anything outside it — including ~/.config/specifyr/mcp.env.

set -euo pipefail

. "$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)/common.sh"

mcp_load_node

# Pinned. server-filesystem is actively maintained (2026.7.10, published
# 2026-07-10), so an unpinned `npx -y` re-resolves from the registry on every
# restart and can change under us between sessions with no record of what moved.
# Bump deliberately.
#
# Routed through sanitize.mjs: the 2026-07 Claude Desktop update rejects
# tools/call against TS-SDK servers whose tool definitions carry
# zod-to-json-schema artifacts ($schema draft-07, outputSchema, annotations).
# The shim scrubs them from tools/list responses; everything else passes
# through untouched. github.sh and graphify.sh (Go/Python SDKs) don't emit
# these and stay unshimmed. See .mcp/sanitize.mjs.
exec node "$MCP_DIR/sanitize.mjs" npx -y @modelcontextprotocol/server-filesystem@2026.7.10 "$MCP_REPO_ROOT"

Sanitize Shim

// .mcp/sanitize.mjs — stdio JSON-RPC shim that scrubs TS-SDK schema artifacts
// Claude Desktop's post-2026-07-update validator rejects.
//
// Usage:  node sanitize.mjs <server-command> [args...]
//
// Why this exists: the MCP TypeScript SDK generates tool inputSchemas via
// zod-to-json-schema, which stamps `$schema: draft-07` into every tool and
// (SDK >=1.26) adds outputSchema/annotations/execution fields. The updated
// Claude Desktop validates tool definitions strictly at tools/call time and
// rejects these — the server spawns and handshakes fine, tools/list succeeds,
// but every tools/call fails app-side before reaching the transport. Go- and
// Python-SDK servers (github.sh, graphify.sh) don't emit these fields and are
// unaffected; only the node servers (filesystem.sh, git.sh) route through this.
//
// What it does:
//   client -> server: passed through untouched, byte for byte.
//   server -> client: tools/list results are scrubbed —
//     - `$schema` removed recursively from each tool's inputSchema
//     - `outputSchema` removed entirely (structuredContent does not require
//       the declaration; shipping it is what trips the validator)
//     - `annotations` and `execution` removed (SDK >=1.26 additions)
//   Everything else — tool calls, results, notifications — is untouched.
//
// Rules honoured from .mcp/README.md: stdout is the protocol (this file never
// writes anything to stdout except transformed protocol lines); stderr is
// inherited so server diagnostics surface normally; nothing is user-specific.
//
// This file is invoked via `node`, so it needs no shebang and no execute bit
// (mode 100644, like common.sh).

import { spawn } from 'node:child_process';

const [cmd, ...args] = process.argv.slice(2);
if (!cmd) {
  process.stderr.write('sanitize.mjs: no server command given\n');
  process.exit(2);
}

const child = spawn(cmd, args, { stdio: ['pipe', 'pipe', 'inherit'] });

child.on('error', (err) => {
  process.stderr.write(`sanitize.mjs: failed to spawn ${cmd}: ${err.message}\n`);
  process.exit(1);
});

// client -> server: transparent.
process.stdin.pipe(child.stdin);

// server -> client: line-buffered transform. MCP stdio framing is
// newline-delimited JSON — one message per line.
let buf = '';
child.stdout.on('data', (chunk) => {
  buf += chunk.toString('utf8');
  let nl;
  while ((nl = buf.indexOf('\n')) >= 0) {
    const line = buf.slice(0, nl);
    buf = buf.slice(nl + 1);
    process.stdout.write(transform(line) + '\n');
  }
});
child.stdout.on('end', () => {
  if (buf.length) process.stdout.write(transform(buf));
});

function transform(line) {
  if (!line.trim()) return line;
  let msg;
  try {
    msg = JSON.parse(line);
  } catch {
    return line; // not JSON (shouldn't happen on a compliant server) — pass through
  }
  if (msg && msg.result && Array.isArray(msg.result.tools)) {
    for (const tool of msg.result.tools) {
      if (tool.inputSchema) stripSchemaKey(tool.inputSchema);
      delete tool.outputSchema;
      delete tool.annotations;
      delete tool.execution;
    }
  }
  return JSON.stringify(msg);
}

function stripSchemaKey(node) {
  if (Array.isArray(node)) {
    for (const item of node) stripSchemaKey(item);
    return;
  }
  if (node && typeof node === 'object') {
    delete node['$schema'];
    for (const value of Object.values(node)) stripSchemaKey(value);
  }
}

child.on('exit', (code, signal) => {
  process.exit(signal ? 1 : (code ?? 0));
});
process.stdin.on('end', () => child.stdin.end());

[inddev]

@tobimax Confirmed working on macOS. Thank you, this cracked it.
Adapted for macOS (no WSL layer needed): dropped sanitize.mjs verbatim next to my servers and invoke it directly:

"project-fs": {
  "command": "node",
  "args": [
    "/Users/USER/code/mcp-shim/sanitize.mjs",
    "/Users/USER/.nvm/versions/node/v20.18.0/bin/mcp-server-filesystem",
    "/Users/USER/code/project"
  ]
}

server-filesystem 2026.7.10 through the shim: dispatch fully restored, first successful tools/call since the 20 July window. Verified the scrub beforehand by piping initialize/tools/list at the shim over raw stdio and grepping the output, with zero $schema/outputSchema remaining.

Your root cause also explains the macOS divergence I reported earlier: 2025.8.21 stamps $schema draft-07 into inputSchema too (visible in its raw tools/list), just without outputSchema/annotations. macOS Desktop apparently validates at registration and rejects on $schema alone, hence "no tools available", while Windows only trips at call time on the newer artifacts. One validator, two enforcement points, stricter on macOS.

Cross-posting to anthropics/claude-code#80094 for macOS visibility.