[BUG] Claude Desktop: MCP tool calls intermittently never dispatched — silent 4-min hangs, all local servers wedge until full restart (both-side logs)

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?

A tools/call issued from chat should be delivered to the target MCP server within milliseconds — the server demonstrably answers in 1–222 ms whenever delivery happens. If dispatch cannot deliver, the call should fail fast with a distinct, logged error ("dispatch stalled") — not hang silently for 4 minutes and wedge every other MCP server until a full app restart.

What Should Happen?

A tools/call issued from chat should be delivered to the target MCP server within milliseconds — the server demonstrably answers in 1–222 ms whenever delivery happens. If dispatch cannot deliver, the call should fail fast with a distinct, logged error ("dispatch stalled") — not hang silently for 4 minutes and wedge every other MCP server until a full app restart.

Error Messages/Logs

No result received from the Claude Desktop app after waiting 4 minutes. The local MCP server providing this tool may be unresponsive, crashed, or not running.

(Server-side wire-log and Claude Desktop mcp-server-winfs.log excerpts for the captured hang are in the linked report — for the hung calls both logs contain nothing: no "Message from client", no RECV on the child's stdin.)

Steps to Reproduce

No deterministic trigger — intermittent; captured with both-side logging:

1. Claude Desktop on Windows 10, 3 local stdio MCP servers enabled (winfs-mcp, Desktop Commander, pdf-viewer), several chat windows.
2. Use tools normally. Degradation appears after sustained use — observed from hours down to minutes after a fresh relaunch.
3. Eventually any tools/call (even a tiny ~150 B read) hangs ~4 minutes → "No result received from the Claude Desktop app after waiting 4 minutes". Retries hang identically; calls to OTHER servers and Claude-in-Chrome wedge in the same window.
4. With logging on: the hung call appears in NO Claude Desktop MCP log (no "Message from client" in mcp-server-*.log, nothing in mcp.log) and never reaches the server child's stdin (no RECV in the server-side wire log). The server is alive — it answered in 5 ms minutes earlier.
5. Full tray-exit + relaunch → first calls succeed in milliseconds.

Full timeline + verbatim two-sided logs: https://github.com/leonovee/winfs-mcp/blob/main/audit/investigations/upstream-claude-desktop-transport-hang.md

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

— note: the bug is in Claude Desktop 1.11847.5.0 x64 (MSIX), not the CLI; version given to satisfy the form.

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

The wedge recurred WHILE preparing this report: within ~2 minutes of a fresh relaunch, after 6 successful browser-bridge calls — degradation is accelerating on this install. Three prior internal investigations ruled out the server (523/523 requests answered since 2026-06-02, zero unanswered ever). Happy to provide full unredacted logs or run a diagnostic build on request.