[BUG] Claude Desktop MCP tool calls silently timeout after 4min on Windows — affects ALL transports, causes UI state corruption

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?

Claude Desktop silently cancels MCP tool calls after exactly 4 minutes with
"MCP error -32001: Request timed out" — even when the MCP server completed the
operation successfully. The file/note is written to disk correctly, but Claude
Desktop never receives or displays the result. This affects ALL MCP transports
tested (stdio and HTTP), making MCP write tools unreliable for any real-world
content on Windows.

What Should Happen?

Claude Desktop should either:

1. Wait for the MCP server to respond (no hardcoded 4-minute client-side timeout), or
2. Make the timeout configurable via claude_desktop_config.json, or
3. At minimum, not corrupt UI state (message_store_sync_blocked cascade) when

a timeout occurs

Error Messages/Logs

From mcp.log — request sent at 00:47:04, cancelled by CLIENT at 00:51:04 (exactly 4 min):

[obsidian] Message from client: {"method":"tools/call","params":{"name":"create-note",
"arguments":{"content":"...[15903 chars]..."}},"jsonrpc":"2.0","id":5}

[obsidian] Message from client: {"jsonrpc":"2.0","method":"notifications/cancelled",
"params":{"requestId":5,"reason":"McpError: MCP error -32001: Request timed out"}}

NOTE: The server never sent a timeout response. The CLIENT cancelled unilaterally.
The file was written to disk successfully — confirmed by checking filesystem.

From claude.ai-web.log — UI corruption after timeout:

[COMPLETION] Request failed Error: Content block index did not match the expected index
[COMPLETION] message_store_sync_blocked [object Object]
[COMPLETION] Failed all attempts to invalidate conversation tree with consistency=eventual
[COMPLETION] message_store_sync_loss_accepted [object Object]

Steps to Reproduce

1. Install any MCP server in claude_desktop_config.json (tested: obsidian-mcp npm v1.0.6,

mcp-obsidian uvx/PyPI, obsidian-mcp-server npm, obsidian-http-mcp HTTP transport)

1. Ask Claude to write a file/note with content exceeding ~500 characters
2. Observe: Claude Desktop shows tool call in progress, no response
3. After exactly 4 minutes: Claude reports "No result received from the Claude

Desktop app after waiting 4 minutes"

1. Check the target file on disk — the write succeeded

Threshold: payloads under ~400 chars succeed instantly. Over ~500 chars = 4min timeout.
Path depth and transport type have no effect — all produce the same result.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.52 (Claude Code)

Claude Code Version

2.1.52 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Tested MCP packages and results:

Package | Transport | Result
obsidian-mcp (npm) | stdio | 4min timeout
mcp-obsidian (uvx) | stdio | 4min timeout
obsidian-mcp-server | stdio | 4min timeout
obsidian-http-mcp | HTTP | 4min timeout

The timeout originates in the Claude Desktop CLIENT — not the server.
The client sends notifications/cancelled after 4min regardless of server state.

Related closed issue: #22542 — closed as "not planned" but that report only
covered stdio transport. This report proves HTTP transport is also affected,
meaning the fix cannot be server-side. The client timeout must be addressed.

Workaround currently in use: generate files externally, package as zip with
folder structure, extract manually to vault. This confirms writes succeed —
the issue is purely client-side result delivery.

Version history:

• Issue confirmed on Claude Desktop v1.569.0 (current latest as of 2026-04-06)
• Issue was also present on previous versions before v1.569.0 — this is NOT a

new regression introduced in 1.569.0, it has persisted across multiple versions

• Downgrade via Windows Store is not possible (no rollback option) so exact

first-affected version cannot be confirmed, but the bug predates the current release

• The issue has been consistently reproducible across multiple Claude Desktop

update cycles, suggesting it is a longstanding architectural issue rather than
a recent regression

Attach: mcp.log, claude.ai-web.log, main.log

claude.ai-web.log
main.log
mcp.log