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

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?

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

1. 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