[BUG] Claude Desktop (Windows): MCP tool calls hard-terminated and bridge wedge after repeated timeouts

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/44032
2. https://github.com/anthropics/claude-code/issues/64614
3. https://github.com/anthropics/claude-code/issues/51043

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is NOT a duplicate that should be auto-closed. The bot points to #44032 as
canonical, but #44032 was closed as "invalid / not about Claude Code" and locked
on 2026-04-17 — and #64614 and #51043 were then auto-closed as duplicates *of that
locked/invalid issue*. Net result: a confirmed, recurring defect has no live tracking
issue. This report is correctly triaged (labels: bug, platform:windows, area:mcp), so
please keep it open as the canonical tracker.

It is OS- and transport-independent — the same defect is described across:

• #44032 (Windows, "all transports", UI state corruption)
• #64614 (remote/hosted connectors, "not configurable")
• #51043 (macOS, Figma MCP)

Concrete, reproducible evidence (this report adds a protocol-level trace the others lack):

• Reproduced on Claude Desktop 1.11187.2 (Windows 11 26200), across 3 consecutive updates.
• mcp.log shows the client sending notifications/cancelled at exactly +4:00

after tools/call, with MCP error -32001: Request timed out — i.e. a hard client-side
cap, server still running.

• A server-advertised timeout_seconds=600 does not bypass it → confirms "not configurable".
• After repeated timeouts the bridge wedges across ALL connected MCP servers (trivial

calls then also hang 4 min until restart) → this is the "UI state corruption" from #44032.

Requested fix (any one): configurable client-side tool-call timeout (per-server/global);
honor MCP progress notifications to extend it; and isolate per-server connections so one
timed-out call cannot wedge other servers.

The real bug here is the cross-server wedge, not the 4-minute cap itself.

After a call hits the cap, all connected MCP servers go unresponsive — unrelated trivial calls also hang for 4 minutes, until a full restart. One stuck call freezing every other server is a missing per-server isolation defect (a shared client-side bridge resource blocked/exhausted). This is a bug regardless of whether the 4-min cap is intentional, and it's why this issue should stay open.

Workaround (local stdio servers you control): you can't fix the client-side isolation, but you can stop your server from ever tripping the wedge — cap each tool call below the ~4-min limit on the server side and return a normal error. It must be race-and-abandon, not cooperative cancellation, since most handlers don't observe a CancellationToken. For .NET / ModelContextProtocol SDK, one CallTool filter does it:

.WithRequestFilters(f => f.AddCallToolFilter(next => async (ctx, ct) =>
{
    var cap  = TimeSpan.FromSeconds(120);             // under the ~240s client cap
    var work = next(ctx, ct).AsTask();
    if (await Task.WhenAny(work, Task.Delay(cap, ct)) == work) return await work;
    _ = work.ContinueWith(t => { _ = t.Exception; }); // observe + abandon
    return new CallToolResult { IsError = true, Content =
        new List<ContentBlock> { new TextContentBlock { Text = "Exceeded server-side cap; abandoned, connector still responsive." } } };
}));

In Claude Desktop (Windows 11, local stdio, C# SDK 1.3): a Start-Sleep 150 call advertising timeout_seconds: 250 returned the error at ~120 s; the next call succeeded in ~170 ms, no wedge (server log: after 120039ms). I can no longer reproduce the cross-server wedge from a well-behaved server.

This doesn't fix the root: a server that doesn't self-cap (or any remote connector you don't control) will still wedge the bridge. The real fix is client-side per-server isolation, so one timed-out call can't take down the others.

Still affected on Claude Desktop for Windows (latest version, July 2026). I use the ioBroker MCP adapter to query InfluxDB history data from my smart home setup. Any history_query over a larger time range triggers the 4-minute timeout. Worse: after 2-3 timeouts, ALL connected MCP servers become unresponsive (the bridge wedge described in #65643). The only recovery is killing all node.exe processes in Task Manager and restarting Claude Desktop — a normal restart doesn't help because the node processes survive the close.
A configurable timeout (or at minimum raising the default to 10 minutes) would make MCP usable for real-world data queries.

macOS confirmation, with server-side log evidence: the timed-out call never reaches the local MCP server

Adding a macOS data point to this report, including local MCP server logs that show where the call is lost. Since this reproduces on macOS, the platform:windows label may be too narrow. Related: #44032 (hard 4-minute client timeout) and #41836 (no session/conversation identifier sent to MCP servers).

Environment

• Claude Desktop 1.22209.3 on macOS 26.5.2, Mac with Apple M5 Max, 64 GB RAM
• Local MCP server: Filesystem desktop extension, launched with the built-in Node.js runtime
• From the initialize exchange in the log: serverInfo = secure-filesystem-server 0.2.0, protocol version 2025-11-25, clientInfo = claude-ai 0.1.0
• Context when it fails: two conversations running at the same time (Claude Desktop in two separate Chats), both routing tool calls through the same Claude Desktop app to the same local server

Symptom

One conversation's list_allowed_directories call, the cheapest tool this server exposes, fails after exactly 4 minutes with the standard message: "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." Unlike the original report, no long-running call is involved on my side; the dropped call is trivial and the server is idle and healthy.

Server-side log (~/Library/Logs/Claude/mcp-server-Filesystem.log, timestamps UTC, { metadata: undefined } suffixes trimmed)

Incident on 2026-07-19. The failing call must have been dispatched between roughly 12:05 and 12:16 UTC (the error was on screen at 12:20:46 UTC). In that window the server receives no tools/call at all. The transport is torn down at 12:14:26 and immediately rebuilt:

2026-07-19T12:01:49.362Z [Filesystem] [info] Message from client: method="tools/call" id=16 params
2026-07-19T12:01:49.368Z [Filesystem] [info] Message from server: id=16 result(1 blocks)
2026-07-19T12:14:26.472Z [Filesystem] [info] Shutting down server...
2026-07-19T12:14:30.286Z [Filesystem] [info] Initializing server...
2026-07-19T12:14:31.108Z [Filesystem] [info] Message from client: method="tools/list" id=1 params
2026-07-19T12:18:46.499Z [Filesystem] [info] Message from client: method="tools/call" id=2 params
2026-07-19T12:18:46.502Z [Filesystem] [info] Message from server: id=2 result(1 blocks)

The dropped call never appears in the log. It is lost inside the Desktop app's bridge before reaching the server process. Every call that is delivered gets a result within milliseconds; the slowest response in several weeks of this log is about 17 seconds for one large read (2026-07-10), nowhere near 240 seconds.

Same signature on 2026-06-18. A connection is opened, handles initialize and tools/list, receives not a single tools/call, and is torn down exactly 4 minutes later, to the second:

2026-06-18T14:04:39.048Z [Filesystem] [info] Message from client: {"method":"initialize", ...} id=0
2026-06-18T14:04:39.193Z [Filesystem] [info] Message from client: {"method":"tools/list", ...} id=1
2026-06-18T14:08:39.633Z [Filesystem] [info] Shutting down server...

Additional observation

Around window/renderer changes ("Server transport closed (renderer released port)") the app opens several connections within the same second (for example 2026-07-08 13:10:52 to 13:11:45 UTC, and 2026-07-17 12:41:52 to 12:42:35 UTC). In my usage the losses cluster around exactly this churn, when two conversations pull on the bridge at once.

Takeaways

• Confirms the issue on macOS; it is not Windows-specific.
• Confirms the error text is misleading: the server is healthy and idle, the call was simply never delivered.
• Supports the fixes requested above, in particular isolating connections so one wedged call cannot block the bridge for every server, honoring progress notifications, and making the timeout configurable.
• Because no conversation identifier reaches the server (#41836), the server side cannot even help disambiguate concurrent conversations.

I can share a redacted copy of the full log file if that helps.

Follow-up with new evidence: a call reported as timed out was delivered, executed in 1 ms, and its result was lost — silent side effects behind the 4-minute error

Same environment as my comment from July 19 above (macOS, Filesystem desktop extension, built-in Node.js runtime). New observations from one morning (2026-07-20, all times UTC), collected across several conversations using the same Desktop app and correlated against mcp-server-Filesystem.log.

1. Lost result with a persisted side effect (data-integrity hazard)

A write_file call from one conversation was reported to the model with the standard error ("No result received from the Claude Desktop app after waiting 4 minutes …"). The server log shows the call was in fact delivered and answered instantly:

2026-07-20T08:50:59.252Z [Filesystem] [info] Message from client: method="tools/call" id=6 params
2026-07-20T08:50:59.254Z [Filesystem] [info] Message from server: id=6 result(1 blocks)

The target file existed on disk afterwards, its contents matching the payload of the "failed" call verbatim, and its birth timestamp equals the delivery time (stat -f "%SB" reports 10:50:59 CEST, i.e. 08:50:59 UTC). Only the success response was lost on its way back to the conversation.

Implication: the timeout message can mask a completed, persisted write. Blindly retrying "failed" calls risks double execution; for non-idempotent tools this is a data-integrity problem, not just a UX problem. Suggested addition to the fix list: when the 4-minute timeout fires, do not silently discard a result that still arrives, and tell the model/user that the operation may nevertheless have completed.

2. Delivery losses also occur with a single conversation

Two further losses hit trivial read_text_file calls on markdown files under 4 KB while no other conversation was issuing tool calls; one of them was the second call immediately after a fresh app start, right after a first call that had returned in milliseconds. Concurrent conversations and window switching aggravate the problem but are not required.

3. Delivery is stochastic; reads and writes are equally affected

An identical edit_file call failed once and succeeded on manual retry. Another write was delivered normally between two losses. Across the whole day, every call that reached the server was answered in milliseconds, and every failure corresponds to a missing tools/call entry in the log (delivery loss), reconfirming the July 19 analysis. The exact-240-second teardown signature appeared again: last delivered call at 07:27:41, then a silent teardown at 08:04:32, i.e. 240 seconds after the reconstructed dispatch of a lost call.

4. Accumulation and wedge

After repeated timeouts, and after further calls were issued despite earlier failures, even trivial calls began timing out until the app was fully restarted — matching the wedge behavior described in this issue.

Happy to share redacted log sections for each of these windows.

Windows/MSIX confirmation of the delivery-loss signature, plus a persistent variant and a separate config-path defect

Corroborating @Fuchskind73's "the call never reaches the server" analysis from the Windows side, on a build very close to the original reporter's.

Environment

• Claude Desktop for Windows, MSIX-packaged (package family Claude_pzs8sxrjxfjjc)
• Windows 11 Pro 10.0.26200 — same OS build as the original report
• Affected: all local stdio servers, both claude_desktop_config.json-declared and Desktop Extension installed
• Not affected: hosted connectors (Google Drive, Gmail, TickTick, Bitly) worked normally throughout the same sessions, which localizes the fault to the local stdio bridge rather than tool-calling generally

Same signature, Windows side

Every local server log shows the complete handshake and then nothing — no error, no disconnect:

[info] Server started and connected successfully
[info] Message from client: method="initialize" id=0
[info] Message from server: id=0 result
[info] Message from client: method="notifications/initialized"
[info] Message from client: method="tools/list" id=1
[info] Message from server: id=1 result

Meanwhile main.log accumulates MCP_TOOL_TIMEOUT events with no corresponding tools/call in any server log at any timestamp. Confirming the point already made in this thread: the client times out on requests it never put on the wire, and the resulting message ("the local MCP server ... may be unresponsive, crashed, or not running") names a component that is provably healthy. On this machine that misdirection cost several weeks of restart and reinstall cycles aimed at servers that were fine the entire time.

The backend was independently exonerated too: for the Obsidian connector, the backing REST service returned a full authenticated listing in under a second during the exact period the connector was reported unresponsive.

What may be new here: a persistent, not intermittent, variant

Reports in this thread describe stochastic loss that a restart clears. Last tools/call actually received per server on this machine:

| Server | Installed via | Last tools/call received |
|---|---|---|
| obsidian-vault | config | 2026-07-17 |
| Windows-MCP | extension | 2026-07-15 |
| Control your Mac | extension | never — zero occurrences |
| PDF Tools | extension | never — zero occurrences |

"Control your Mac" has been installed, isEnabled: true, and starting cleanly across many app restarts since 2026-07-02 — eighteen days — and its log contains not one tools/call. If that is the same defect, it is not self-clearing on restart for every connector, which would matter for how the fix is validated.

Limitation, stated plainly: MCP_TOOL_TIMEOUT entries in main.log are global rather than per-connector, so I cannot prove from logs alone that a call was attempted against that specific connector and dropped, versus never attempted. PDF Tools in particular may simply be unused. I am reporting the observation, not asserting the attribution.

Separate defect that compounds diagnosis on Windows: config-path divergence

%APPDATA%\Claude\claude_desktop_config.json does not exist on this machine. The MSIX build reads only the virtualized copy under:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\

Documentation and most third-party setup guides reference the %APPDATA% path. An edit written there succeeds and has no effect — no warning, no error, no indication the file is not the one being read. This is independent of the dispatch bug, but it means anyone on MSIX debugging the dispatch bug is liable to spend a cycle "fixing" a config the app never reads.

A startup warning when a config file exists at the unread path would remove that class of confusion entirely.

Related trap for anyone else diagnosing on Windows: Desktop Extensions never appear in claude_desktop_config.json at all — they live in Claude Extensions\ with an isEnabled flag in Claude Extensions Settings\<id>.json. Reading only the config file makes extension-installed connectors look unregistered. I made exactly that error before catching it.

The one diagnostic change that would have mattered most

Independent of root cause, the timeout message should distinguish:

• a request that was transmitted and not answered → server-side problem
• a request that was never transmitted → client-side problem

The current text asserts the first in a case that is provably the second. That single distinction would have cut this investigation from weeks to minutes, and going by this thread, the same is true for several other people here.

Thanks for the detailed writeup - this lines up with what I found on my end
too. After a hung history_query call, I closed Claude Desktop completely,
and Task Manager still showed 5 "Node.js JavaScript Runtime" processes
running afterward, holding around 43% of RAM between them. So a plain
close/restart clearly doesn't reliably tear down the mcp-remote child
processes on my machine either - matches your point that this doesn't
self-clear for every connector.

Can also confirm the config-path issue from the MSIX side: we're on the
MSIX build too, and %APPDATA%\Claude\claude_desktop_config.json here is
exactly the stale copy you'd expect - last modified once, never touched
again after we found the real path. The live config is under
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\.
Same package family ID as yours, for what it's worth - seems to be fixed
per-app rather than per-install.

The "request never transmitted vs. sent-but-no-response" distinction you're
asking for would have saved me time too - I initially assumed my local
ioBroker MCP adapter itself was the problem and restarted that for nothing
before finding this thread.

Am Mo., 20. Juli 2026 um 16:09 Uhr schrieb haloeight <
@.***>:

haloeight left a comment (anthropics/claude-code#65643) <https://github.com/anthropics/claude-code/issues/65643#issuecomment-5023187836> Windows/MSIX confirmation of the delivery-loss signature, plus a persistent variant and a separate config-path defect Corroborating @Fuchskind73 <https://github.com/Fuchskind73>'s "the call never reaches the server" analysis from the Windows side, on a build very close to the original reporter's. Environment - Claude Desktop for Windows, MSIX-packaged (package family Claude_pzs8sxrjxfjjc) - Windows 11 Pro 10.0.26200 — same OS build as the original report - Affected: all local stdio servers, both claude_desktop_config.json-declared and Desktop Extension installed - Not affected: hosted connectors (Google Drive, Gmail, TickTick, Bitly) worked normally throughout the same sessions, which localizes the fault to the local stdio bridge rather than tool-calling generally Same signature, Windows side Every local server log shows the complete handshake and then nothing — no error, no disconnect: [info] Server started and connected successfully [info] Message from client: method="initialize" id=0 [info] Message from server: id=0 result [info] Message from client: method="notifications/initialized" [info] Message from client: method="tools/list" id=1 [info] Message from server: id=1 result Meanwhile main.log accumulates MCP_TOOL_TIMEOUT events with no corresponding tools/call in any server log at any timestamp. Confirming the point already made in this thread: the client times out on requests it never put on the wire, and the resulting message ("the local MCP server ... may be unresponsive, crashed, or not running") names a component that is provably healthy. On this machine that misdirection cost several weeks of restart and reinstall cycles aimed at servers that were fine the entire time. The backend was independently exonerated too: for the Obsidian connector, the backing REST service returned a full authenticated listing in under a second during the exact period the connector was reported unresponsive. What may be new here: a persistent, not intermittent, variant Reports in this thread describe stochastic loss that a restart clears. Last tools/call actually received per server on this machine: Server Installed via Last tools/call received obsidian-vault config 2026-07-17 Windows-MCP extension 2026-07-15 Control your Mac extension never — zero occurrences PDF Tools extension never — zero occurrences "Control your Mac" has been installed, isEnabled: true, and starting cleanly across many app restarts since 2026-07-02 — eighteen days — and its log contains not one tools/call. If that is the same defect, it is not self-clearing on restart for every connector, which would matter for how the fix is validated. Limitation, stated plainly: MCP_TOOL_TIMEOUT entries in main.log are global rather than per-connector, so I cannot prove from logs alone that a call was attempted against that specific connector and dropped, versus never attempted. PDF Tools in particular may simply be unused. I am reporting the observation, not asserting the attribution. Separate defect that compounds diagnosis on Windows: config-path divergence %APPDATA%\Claude\claude_desktop_config.json does not exist on this machine. The MSIX build reads only the virtualized copy under: %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ Documentation and most third-party setup guides reference the %APPDATA% path. An edit written there succeeds and has no effect — no warning, no error, no indication the file is not the one being read. This is independent of the dispatch bug, but it means anyone on MSIX debugging the dispatch bug is liable to spend a cycle "fixing" a config the app never reads. A startup warning when a config file exists at the unread path would remove that class of confusion entirely. Related trap for anyone else diagnosing on Windows: Desktop Extensions never appear in claude_desktop_config.json at all — they live in Claude Extensions\ with an isEnabled flag in Claude Extensions Settings\<id>.json. Reading only the config file makes extension-installed connectors look unregistered. I made exactly that error before catching it. The one diagnostic change that would have mattered most Independent of root cause, the timeout message should distinguish: - a request that was transmitted and not answered → server-side problem - a request that was never transmitted → client-side problem The current text asserts the first in a case that is provably the second. That single distinction would have cut this investigation from weeks to minutes, and going by this thread, the same is true for several other people here. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/65643?email_source=notifications&email_token=CDYTVXHSXNQ4FHX3VRCTAH35FYR3NA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBSGMYTQNZYGM3KM4TFMFZW63VGNVQW45LBNSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5023187836>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CDYTVXG6Y2BF6DFFHERBHLD5FYR3NAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TINJZG4YDENBYGAZKC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CDYTVXHPB5IDDQI3UBOV5JD5FYR3NA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBSGMYTQNZYGM3KM4TFMFZW63VGNVQW45LBNSSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/CDYTVXD4BRXWAB5YTYC7H535FYR3NA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBSGMYTQNZYGM3KM4TFMFZW63VGNVQW45LBNSSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: @.***>