claude-code - 💡(How to fix) Fix [BUG] Claude Desktop (Windows): MCP tool calls hard-terminated and bridge wedge after repeated timeouts

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

On Claude Desktop for Windows, any MCP tool call whose execution exceeds ~4 minutes (~240 s) is terminated client-side with: "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." The MCP server is healthy and still processing; it returns normally when the same call finishes faster. The displayed message is misleading (it blames the server, which is fine). A more severe secondary effect: after a few such timeouts the bridge wedges across ALL connected MCP servers (see below).

Error Message

~240 s cap on every tool call, ignoring any server-side timeout; misleading error text; 5. Fix the misleading error text (server is healthy, not crashed).

Error Messages/Logs

Root Cause

On Claude Desktop for Windows, any MCP tool call whose execution exceeds ~4 minutes (~240 s) is terminated client-side with: "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." The MCP server is healthy and still processing; it returns normally when the same call finishes faster. The displayed message is misleading (it blames the server, which is fine). A more severe secondary effect: after a few such timeouts the bridge wedges across ALL connected MCP servers (see below).

Code Example

Tool result could not be submitted. The request may have expired or the connection was interrupted. Refresh the page to continue.
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

Bug Report — Claude Desktop (Windows): MCP tool calls hard-terminated at ~4 minutes, and bridge wedge after repeated timeouts

Summary

On Claude Desktop for Windows, any MCP tool call whose execution exceeds ~4 minutes (~240 s) is terminated client-side with: "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." The MCP server is healthy and still processing; it returns normally when the same call finishes faster. The displayed message is misleading (it blames the server, which is fine). A more severe secondary effect: after a few such timeouts the bridge wedges across ALL connected MCP servers (see below).

Environment

  • Claude Desktop: 1.11187.1 (MSIX package Claude_1.11187.1.0_x64__pzs8sxrjxfjjc)
  • OS: Windows 11 Pro, build 10.0.26200
  • MCP server(s): local stdio servers (custom), C# MCP SDK 1.3, launched by Claude Desktop
  • Transport: local stdio

Severity / Impact

Medium–High for infrastructure/automation use. Blocks any MCP tool whose single call runs

~4 min (DISM /Online /Cleanup-Image /ScanHealth, sfc, long SQL queries, backups, large file ops, long scripts). The secondary wedge requires restarting MCP servers / the app.

Expected behavior

Long calls run to completion, OR the client honors a configurable/request-level timeout. A single timed-out call must never wedge other healthy MCP servers. MCP supports long-running operations and progress notifications; a fixed client cap should not silently kill them.

Actual behavior

~240 s cap on every tool call, ignoring any server-side timeout; misleading error text; cross-server wedge after repeated timeouts.

Evidence / Diagnosis — it is the client/bridge, not the server

  • Multiple runs of Start-Sleep 280 all terminated at ~4 min.
  • The tool exposes a server-side timeout_seconds parameter; setting it to 600 does NOT change the outcome -> the cap is in the Claude Desktop MCP client, not the server.
  • A trivial call immediately after a single terminated long call returned in <200 ms (server healthy); but after further timeouts, trivial calls on ALL connected servers also hung 4 min.

Tested across versions

Reproduced consistently across multiple Claude Desktop updates, including 1.11187.2 (latest as of testing).

Requested fix (any of)

  1. Make the MCP tool-call timeout configurable (per-server and/or global).
  2. Honor MCP progress notifications to reset/extend the timeout.
  3. Raise/remove the fixed cap for local stdio servers.
  4. Isolate per-server connections so one timed-out call cannot wedge other MCP servers.
  5. Fix the misleading error text (server is healthy, not crashed).

What Should Happen?

To work normally with MCP tools

Error Messages/Logs

Tool result could not be submitted. The request may have expired or the connection was interrupted. Refresh the page to continue.

Steps to Reproduce

Steps to reproduce — primary (4-min cap)

  1. Connect any local stdio MCP server exposing a long-running tool.
  2. Invoke a call that takes > ~4 minutes, e.g.: Start-Sleep -Seconds 280 # 4m40s
  3. The call is terminated at ~4 minutes; the result is never returned.

Steps to reproduce — secondary (bridge wedge)

  1. Trigger the 4-min timeout above 2–3 times (and/or a long-timed-out call on a second MCP server).
  2. Issue a TRIVIAL call afterwards (1-line command, server timeout 30 s).
  3. Observed: after the first one or two timeouts a trivial call may still recover (<200 ms), but after repeated timeouts every connected MCP server becomes unresponsive — trivial calls then also time out at the same 4-minute mark — until the user restarts the MCP servers / Claude Desktop. Points to a shared client-side bridge resource (connection/worker pool or event loop) being exhausted/blocked by the capped-but-still-running requests.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

Claude 1.11187.2 (8cc3af) 2026-06-05T04:43:40.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

mcp_log.zip

Claude-MCP-4min-evidence.zip

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Long calls run to completion, OR the client honors a configurable/request-level timeout. A single timed-out call must never wedge other healthy MCP servers. MCP supports long-running operations and progress notifications; a fixed client cap should not silently kill them.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING