[BUG] Claude Desktop drops large write_file MCP calls before reaching the server (no tools/call ever sent), reads always work — macOS Tahoe 26.2

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?

Environment

| Field | Detail |
|---|---|
| OS | macOS Tahoe 26.2 |
| Hardware | iMac (Apple Silicon) |
| Claude Desktop version | 1.3883.0 |
| Plan | Pro |
| Node.js | Homebrew, /opt/homebrew/bin/node |
| MCP server | @modelcontextprotocol/server-filesystem 2026.1.14, installed globally |
| Server launch | node /opt/homebrew/lib/node_modules/@modelcontextprotocol/server-filesystem/dist/index.js /Users/<user>/Desktop (no npx) |
| Second MCP server | @negokaz/excel-mcp-server (works fine for reads, untested at scale for writes) |

What's wrong

In a stable percentage of sessions, the Claude Desktop MCP client silently drops tools/call requests for write_file (and edit_file with large edits) before they reach the MCP filesystem server.

The user-facing symptom is the UI message "the MCP server is not responding". However, the server is fully alive and responsive — every read tool call (list_directory, read_text_file, read_multiple_files, get_file_info, directory_tree, search_files, list_allowed_directories) succeeds in milliseconds in the same session, immediately before and after the failing write.

Critically, when a large write fails:

• ~/Library/Logs/Claude/mcp.log shows the handshake completed normally and shows zero tools/call for the failing write.
• ~/Library/Logs/Claude/mcp-server-escritorio.log shows zero new entries for the failing write.
• The server process is alive and is not reset.
• The file is not written to disk.

This means the client never sent the request to the server. This is not the 4-minute client-side cancellation pattern described in #44032 (where the server does receive the call and does complete it; in that bug the file is on disk and the client cancels after 4 minutes). Here the client aborts internally before dispatching the call.

The asymmetry is the key signal

In the same session, on the same handle, with the same server PID:

• Reads of any size: always succeed.
• Writes < ~500 bytes: succeed.
• Single small edit_file (< ~500 chars per edit): succeeds.
• write_file with content > ~2-3 KB: silent drop, "server not responding" without server ever seeing the call.
• edit_file with multiple large edits in one call: silent drop.
• edit_file with a single edit > ~1 KB: silent drop.

This rules out a generic transport / handle / permissions issue. It points to a code path in the Claude Desktop MCP dispatcher that handles tools/call arguments with large content strings differently from reads and small writes, and aborts the call instead of forwarding it over stdio when some internal condition is met.

What Should Happen?

Expected behavior

Either: the tools/call is dispatched to the server (which would handle a 3 KB payload in a few milliseconds, as confirmed by hundreds of successful 1-7 KB edits in the same logs on previous days), or: a clear error message is shown indicating why the client refused to dispatch.

Actual behavior

The UI returns "the MCP server is not responding" while the server is alive, healthy, and responsive to other tool calls. No log entry is produced.

Workarounds tested (none resolves the issue)

• Reinstalling the server globally instead of via npx → no effect.
• Excluding ~/Desktop from Spotlight → no effect.
• iCloud Drive does not sync ~/Desktop on this Mac → ruled out.
• Restarting Claude Desktop → temporarily restores writes, but the issue resurfaces sometimes within the same fresh session.
• Norton Antivirus latency benchmarked at 0.275s for a 5 KB direct Node write to ~/Desktop → ruled out as a contributing factor.

Error Messages/Logs

## Logs

`mcp.log` and `mcp-server-escritorio.log` available on request. The relevant pattern in the logs is:

1. Successful handshake at session start (`initialize` → `tools/list` → done in ~30ms).
2. Successful read calls during the session.
3. The user requests a large write through the chat UI.
4. UI shows "the MCP server is not responding".
5. **No new line appears in either MCP log.**
6. Subsequent reads in the same session still work.

## Impact

This is blocking real production use of the filesystem MCP server. Reads are reliable but any workflow that requires Claude to author or update local documents (project notes, generated reports, configuration files, multi-paragraph rewrites of existing docs) is unreliable. Affected users have no way to predict in which sessions writes will work, and no workaround beyond restarting the app and hoping.

Steps to Reproduce

Steps to reproduce

1. Configure Claude Desktop with the official filesystem MCP server pointing to ~/Desktop, using node directly (not npx), via the global install path.
2. Open a chat. Ask Claude to write a 200-line markdown file (~3 KB) to the allowed directory.
3. Optionally: in another terminal, run tail -f ~/Library/Logs/Claude/mcp.log ~/Library/Logs/Claude/mcp-server-escritorio.log.

In approximately 30-50% of fresh sessions tested over multiple days, the result is "the MCP server is not responding" with no log activity on either MCP log. Reads in the same session continue to work indefinitely.

##

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.4758

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

mcp-server-escritorio.log
mcp.log