[BUG] Claude Desktop MCP: misleading "server may be unresponsive" 4-minute timeout message, and application logging lost since ~1.34493
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?
Two related problems in Claude Desktop's MCP client (this template is Claude Code's, but the claude-ai-mcp repo no longer accepts issues; the behavior is in the Claude Desktop app).
Issue 1 - the 4-minute timeout message asserts a server state the client cannot know, and its advice is harmful.
Intermittently, an MCP tool call produces ~240 seconds of silence and then this client-side message (verbatim):
"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. Further calls to this tool are likely to time out the same way; consider using an alternative approach or ask the user to restart their local MCP servers."
In every recorded incident this diagnosis was wrong. Examples from one day, timestamped and disk-verified: a directory listing of a small known directory timed out; within minutes the same server answered a metadata probe instantly, created a directory, completed a 5,693-byte write, and served a 30,822-byte read - no restart. Another: a ~20 KB write timed out, a metadata probe showed the write never reached the filesystem, and an immediate reissue completed (22,244 bytes on disk). Per-minute process sampling shows the Claude Desktop process tree continuously up across a 4-hour span containing several such events, with commit, handle and thread counts flat at every incident. The same signature recurs on 1.40609.1.0.
(a) "further calls will likely time out the same way" was false every time - the next call typically returns instantly. (b) "restart your local MCP servers" tells users to restart a demonstrably healthy service, destroying the transient state that would let anyone diagnose the real fault. The client cannot distinguish "server unresponsive" from "request never dispatched"; our disk evidence (writes that never landed, then landed on reissue with no restart) is consistent with the latter.
Issue 2 - application logging disappeared at a build transition and has not returned.
Through 1.32885.1.0 Claude Desktop wrote main.log by default. Our monitoring recorded, machine-generated on 2026-08-21 00:22:31, a live main.log line and in the same sample the build change 1.32885.1.0 -> 1.34493.1.0; every sample since shows no log. main.log still exists but has not been written since 2026-08-20 17:19 local, through 1.37937.0 and 1.40609.1.0. Chromium-layer logging (ELECTRON_ENABLE_LOGGING) shows one line per tool dispatch but no completion/response/error events, and is overwritten on every restart. Net effect: when Issue 1 fires there is no log on either side to attach.
What Should Happen?
- On a 4-minute timeout, the message should state only what the client knows: e.g. "No response was received within 4 minutes; the request may not have been delivered." The "restart your local MCP servers" advice should be removed, or gated on an actual health probe of the server process, and the "further calls will likely time out" prediction dropped - it is contradicted by observed behaviour.
- Claude Desktop should restore application logging (main.log) as it existed through 1.32885.1.0, or emit completion/response/error events at the Chromium logging layer, so affected users can attach actionable diagnostics instead of anecdotes.
Error Messages/Logs
Client-side message, captured verbatim (Claude Desktop 1.40609.1.0, also 1.37937.0):
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. Further calls to this tool are likely to time out the same way; consider using an alternative approach or ask the user to restart their local MCP servers.
Application log: none available - %APPDATA%\Claude\logs\main.log last written 2026-08-20 17:19 local (build 1.32885.1.0); no writes since the 1.34493.1.0 update or on any later build.
Chromium log (ELECTRON_ENABLE_LOGGING=1): one dispatch line per tool call, no completion/response/error line, file overwritten on each client restart - a timed-out call and a successful call are indistinguishable.
Timestamped, disk-verified incident records (file sizes before/after, process-sampling tables) available on request.Steps to Reproduce
Issue 1 (intermittent - cannot be triggered on demand; reaches double digits per working day at peak in our environment):
- Claude Desktop 1.40609.1.0 on Windows 10, MCP filesystem server (@modelcontextprotocol/server-filesystem 2026.7.10, MCP SDK ^1.29.x) spawned natively over stdio, pointed at a large local project tree.
- Work normally in a chat that makes many filesystem tool calls (reads, writes, directory listings).
- Intermittently one call goes silent for ~240 s and returns the message above.
- An immediate reissue frequently times out the same way (a second ~240 s). The call is not recovered by retrying within the same turn.
- After the user waits ~3+ minutes and sends any new message, the next call to the same server returns instantly - no restart of the server, the app, or anything else. The server process tree is continuously up throughout (per-minute process sampling).
- If the timed-out call was a write, a stat of the target shows the write never landed; the later reissue lands and verifies on disk.
Observed pattern: the stall is time-bound and clears on its own; it behaves like a request that was never dispatched (or a stuck dispatch that times out), not a dead server.
The message text itself is shipped behavior and can be reviewed without a repro.
Issue 2 (deterministic):
- Install Claude Desktop >= 1.34493.1.0 on Windows.
- Use the app, including MCP tool calls.
- Observe %APPDATA%\Claude\logs\main.log receives no writes (contrast: written continuously through 1.32885.1.0).
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
1.32885.1.0 - applies to Issue 2 (logging) only. Issue 1 (MCP timeouts/wedging) has been present in every Claude Desktop version we have used, from the first.
Claude Code Version
N/A
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
Filing here because anthropics/claude-ai-mcp no longer accepts new issues. Prior reports by this account on that repo: #703 (2026-07-25) and #726 (2026-07-29) - same environment, related MCP dispatch behaviour.
Context: a single-developer shop running a multi-window Claude Desktop workflow with heavy MCP filesystem use against a large local project tree, on an older Windows 10 machine (ESU). Hypothesis, not yet measured: the stall may be timing-sensitive and more visible on slower hardware, which would explain why it is not reproduced in testing on current machines. We are instrumenting locally and will add timing data to this thread.
No workaround exists: the stall blocks the core function (tool calls), retrying within the turn does not clear it, and the app gives no log to diagnose it. Paying Max-subscription customer; timestamped, disk-verified incident records available on request.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
0. On the "invalid" label
The "bug" label was removed and "invalid" applied by github-actions automation 18 hours after filing, with no human comment and no stated reason. If the trigger was the template (this is Claude Code's template; the defect is in Claude Desktop's MCP client, and the claude-ai-mcp repository no longer accepts issues), please say where Claude Desktop MCP-client defects should be filed and I will move it. If the trigger was anything else, a one-line reason would let me correct it. Until then this issue is the only open record of the defect.
Follow-up with fleet-scale evidence (same reporter, one machine, 6 days, 13 sessions)
Adding data collected since filing. Everything below is from our own logs; nothing is inferred from other reports.
1. What the defect looks like from the outside (mechanism, not just symptom)
A tool call to a local stdio MCP server (the reference filesystem server, launched by Claude Desktop) neither returns nor errors. The client reports after ~4 minutes that no result was received. The server process is alive the whole time: our sampler records the Claude Desktop process start time once a minute, and across the certified windows it never changes, so no crash or restart is involved. On the next user message the same call usually succeeds instantly. The shape is a pending request that hangs on a healthy transport instead of erroring - the same shape the MCP python-sdk fixed by erroring pending requests when the transport closes.
2. Reproducibility across sessions and days (log depth in place of reporter count)
We are a single reporter, so we substitute duration and count for votes; stating that explicitly rather than implying equivalence.
3. No workaround; it blocks a core function
Every session that uses the filesystem server pays ~4 minutes per hang, plus a probe (often another 4). Our working protocol is: two consecutive hangs = stop using the mount for the rest of the turn and hand-deliver the file via PowerShell. That is a fallback, not a workaround: the affected function (read/write through the MCP server) is the whole reason the server is configured. Restarting Claude Desktop is not required for recovery and does not prevent recurrence (certified: no restart across a >33-hour session, wedges throughout). A support ticket on this defect has received no acknowledgement or response; our mailbox shows zero Anthropic support contact of any kind in the past twelve months, and this build has no in-app report path.
4. Blast radius
Any Windows user running a local stdio MCP server through Claude Desktop is exposed; per-event cost is fixed (~4 min), so sessions with many small file operations - exactly the agentic pattern the product encourages - are hit hardest. Older or lower-end hardware is the plausible aggravator (see 6), and that hardware share is large outside North America and Europe; we cite that as context, not as a measurement.
5. Diagnostic gap (a question, not a charge)
Earlier builds wrote logs that let us diagnose where the stall sat; a later build removed that logging, and as far as our records show that is the only regression between versions - the wedge itself has been present since our first Claude Desktop build. Could that logging be restored, or is there an intended diagnostic path for MCP transport stalls we should use instead?
6. Hypothesis (labelled as such)
Resident antivirus real-time scanning delaying child-process spawn or first I/O, compounded by disk latency, pushing the first stdio exchange past an undocumented client-side timeout. On this machine the live engine is Bitdefender (Windows Defender real-time protection is off), so if a scanner is involved it is Bitdefender, not Defender. Consistent with the first-op-after-idle pattern; not yet measured end to end on our side. We are instrumenting spawn-to-first-response timing with AV state recorded per event and will attach results here.
7. Environment
Happy to supply the full ledger (CSV) or run any specific trace you name.
Cross-references (same defect class, prior reports on this repo)
For anyone triaging: the client-side drop of a healthy MCP server's result is not new to this tracker. Related reports, all Windows and/or Claude Desktop, none resolved for Desktop:
What this issue adds: timestamped, disk-verified records that the server stays healthy and answers a probe instantly while the client reports a 4-minute timeout, on builds 1.37937.0, 1.40609.1.0 and 1.46388.2 - i.e. the request is never dispatched or the result is dropped client-side, not a dead server. Most of the linked threads are locked, so this is the open thread for the class. If your setup still reproduces, OS, build, disk type and antivirus state here would help size it. No workaround is known on our side.
Status 2026-09-05: still reproducing on 1.46388.2; new information; request to re-evaluate "invalid"
Repro is current. Claude Desktop 1.46388.2 (MSIX), Windows 10 Pro 19045, native stdio, server-filesystem 2026.7.10. Two more instances since my last comment (09-03 22:5x, 09-04 09:3x PT), same signature: ~240 s silence, the "server may be unresponsive" message, an immediate metadata probe of the same target answers instantly, the timed-out write never reached the filesystem, reissue lands, no restart. Per-minute CPU/disk/antivirus telemetry (Bitdefender real-time on, Defender passive) is now collected around every event; an evidence card follows once a full window is captured.
New information. In support conversation 215475794929874 (09-05) the support agent stated the 240 s timeout is a fixed Desktop limit that fires when the first bytes of a result do not arrive in time, and that this is expected behavior because the server "does all its work before sending anything back". That fits a slow directory walk. It does not fit the disk: (1) a get_file_info on one known file, no work phase, timed out; (2) timed-out writes left no file, not a partial one, so the request never reached the server; (3) the same calls complete in milliseconds seconds later. Consistent with #22542 (result dropped on a hardcoded client timeout) and, on the request side, anthropics/claude-code#726 (wire-level). If there is a first-bytes timer, the evidence says the request is sometimes never dispatched.
On "invalid" (automation, 09-04, no human comment): I understand the lifecycle closes non-Claude-Code reports in 3 days. Claude Code ships inside Claude Desktop (the Code tab), this repo already tracks Desktop MCP behavior (#22542, #5221, the ten issues above), and the venue the nudge points to is the support path recorded here: three conversations (215475233878353 on 07-25; 215475792203583 and 215475794929874 on 09-04/05), no human reply. If there is a correct repo or team for Desktop MCP client defects, name it and I will move this intact.
The ask stands: one human owner. I post only when there is new evidence.