Desktop app MCP Tools hanging for 5-10 minutes then failing.

[bimnow]

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?

Environment

• Product: Claude Desktop (Windows GUI app, NOT Claude Code CLI)
• Version: 1.1.1520 (48ced7)
• OS: Windows 11
• Date Started: February 1, 2026

Bug Description

ALL MCP tool calls hang for exactly ~5 minutes, then fail with "No result received from client-side tool execution". This makes Claude Desktop completely unusable for any MCP-based workflows.

Reproduction Steps

1. Configure any MCP server (SSH, filesystem, etc.)
2. Attempt to use MCP tool
3. Observe 5+ minute hang
4. Tool fails with "No result received from client-side tool execution"

Tested MCP Servers (ALL FAIL):

• SSH server (custom tradasite server to 91.99.146.87)
• Filesystem servers
• All operations timeout

Timing Evidence

Test performed: 21:20:05 → 21:25:46 = 5 minutes 41 seconds hang

Expected Behavior

MCP tools should execute within seconds, not hang for 5+ minutes

Actual Behavior

• 5+ minute freeze
• No progress indication
• Eventually fails with "No result received"
• Operation never executes on server

Screenshots

[Attach your 3 screenshots showing the hang and timestamps]

Related Issues

May be related to Claude Code MCP hanging bugs reported Jan 31, 2026:

• v2.1.27 hangs at 100% CPU after first response (v2.1.25 works) #22158 (v2.1.27 hangs at 100% CPU)
• v2.1.23+ causes 100% CPU hang with multiple parallel instances and hooks #22172 (v2.1.23+ parallel instance hangs)
• [CRITICAL] MCP Server Causes 16+ Hour Hang - No Timeout or Stuck Detection #15945 (CRITICAL MCP Server 16+ hour hang)

Impact

CRITICAL - Production blocking

• Unusable for development workflows
• All MCP functionality broken
• No workaround available

Request

Emergency hotfix needed - this version is completely broken for MCP users.

What Should Happen?

Claude should connect to my server instantly (5 seconds), perform coding tasks, and summerise without delays.

Error Messages/Logs

The command didn't return output. Let me try a simpler search.
No result received from client-side tool execution.

Steps to Reproduce

Steps to Reproduce

1. Install Claude Desktop version 1.1.1520 (Windows)

2. Configure a simple filesystem MCP server in %APPDATA%\Claude\claude_desktop_config.json:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "C:\\Users\\%USERNAME%\\Documents"
      ]
    }
  }
}

3. Restart Claude Desktop completely (close and reopen)

4. Verify MCP server connected - check for hammer icon (🔨) in chat input box

5. Start timer - note current time (HH:MM:SS)

6. Send this prompt:

   Please use the filesystem MCP tool to list all files in Documents folder

7. Observe the hang:

   • MCP tool call is initiated
   • Application shows spinner/loading state
   • Application becomes unresponsive
   • Wait and time it - will hang for approximately 5+ minutes
   • Eventually fails with error: "No result received from client-side tool execution"

8. Record end time - note when error appears (HH:MM:SS)

9. Calculate duration - should be approximately 5-6 minutes

Minimal Example

Config file location: %APPDATA%\Claude\claude_desktop_config.json

Config content:

{
  "mcpServers": {
    "test-filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "C:\\temp"]
      }
  }
}

Test prompt: "Use the test-filesystem MCP to create test.txt with content 'hello'"

Expected: File created in ~1-5 seconds
Actual: 5+ minute hang, then failure with "No result received"

Timing Evidence from Real Test

• Start: 21:20:05
• End: 21:25:46
• Duration: 5 minutes 41 seconds
• Result: Operation failed, MCP tool never executed

Reproduced On

• Windows 11
• Claude Desktop v1.1.1520 (48ced7)
• Multiple different MCP servers (filesystem, SSH, custom servers)
• All MCP tools exhibit identical ~5 minute timeout behavior

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

1.1.1520 (48ced7)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

No response

[sonofsmog]

Same as

#22299
and
#22319

I looked further into it and the MCP server works once per tool call the next call never makes it to the server. Any MCP server. You can see other threads on the Claude Chrome extension basically failing the same way. All Claude Desktop and Chrome MCP servers are affected.

[dnielso5]

my desktop app hasn't been able to read my filesystem for almost 3 days now.

[jonejacobsen]

Same issue here (MacOS), filesystem access is completely broken

[sonofsmog]

my desktop app hasn't been able to read my filesystem for almost 3 days now.

The workaround from Reddit is to actually open the collapesed tool calls and they will go through:

https://www.reddit.com/r/ClaudeAI/comments/1qtspwj/claude_will_not_think_until_i_click_the_collapse/

Why the MCP is tied to the UI like that the world will never know.

[cygnussystems]

Ok , MCP tools are not working properly. I use Desktop Commander and now it works sporadically and hangs a lot. I wish Claude Desktop commander would ask me if I want to install an new version . Maybe it did :-) But now I need to revert to an older version - kind of annoying!

[pratik-pednekar]

Resumed coding after a week and was frustrated to see this issue. The tool call for locating, reading, moving or making changes to the files all have become extremely slow. They dont progress unless you expand the tool call in the chat. I am using Claude Chat on Claude desktop and heavily rely on the MCP extension to make changes and directly work w the codebase.

Has this issue propped up recently (past couple of days)? Has anyone had any luck from reinstalling the connectors or any other methods?

[DoMx]

Resumed coding after a week and was frustrated to see this issue. The tool call for locating, reading, moving or making changes to the files all have become extremely slow. They dont progress unless you expand the tool call in the chat. I am using Claude Chat on Claude desktop and heavily rely on the MCP extension to make changes and directly work w the codebase.

Has this issue propped up recently (past couple of days)? Has anyone had any luck from reinstalling the connectors or any other methods?

Yes, I've tried reinstalling everything. Every MCP connection and Claude Desktop and the issue still persists. This has been an issue since Friday. I read on another bug report that rolling back Claude Desktop versions doesn't help either. 4 days without MCP tools is inexcusable on a $200/mo subscription.

[JavaDerek]

macOS confirmation + server-side evidence that calls never leave the client

Environment: macOS Sequoia (Darwin 24.6.0), 4 custom Python MCP servers (stdio transport), Claude Desktop latest

Server-side proof: tool calls never reach the servers

I have Langfuse tracing wired into all my MCP server call_tool() handlers. During failures, I queried the Langfuse REST API to check whether tool calls actually reached the server processes. Key finding:

• When tools succeed: Langfuse traces appear within seconds (confirmed server-side)
• When tools fail with "No result received": Zero Langfuse traces — the JSON-RPC messages never leave Claude Desktop
• Server processes never crash: Same PIDs throughout all failure/success cycles (verified with ps aux)

This confirms the bug is entirely client-side. The servers are healthy and waiting; Claude Desktop just isn't sending the messages down the stdio pipe.

Controlled workaround test: expanding tool call UI boxes

Confirming @sonofsmog's workaround from the Reddit thread — clicking to expand the MCP tool call UI boxes unblocks the stdio pipe. Tested systematically:

Round	Method	Boxes expanded?	Result
1	Same 4 tools across 4 servers	No	3 of 4 failed (only Morgan succeeded). Langfuse: 1 trace.
2	Same 4 tools	Yes (clicked each)	4/4 succeeded
3	Same 4 tools	Yes	4/4 succeeded
4	Same 4 tools	Yes	4/4 succeeded
5	4 completely different methods	Yes	4/4 succeeded on first call

Without expanding: failures. With expanding: 100% success across 5 consecutive rounds including novel methods. The workaround is reliable on macOS.

Visible symptom: slow text rendering correlates with blocked pipe

When tool calls are about to fail, Claude Desktop's text output slows to ~1 character per 5 seconds for the first few words, then suddenly "snaps" back to normal speed before displaying the failure. This happened consistently across multiple failure instances and suggests the UI render thread is blocked on the stale stdio read.

Selective failure mode (not reported by others yet)

In addition to the all-tools-fail scenario, I observed a selective failure mode: Claude Desktop called 4 different MCP servers, but only 1 responded (Morgan). The other 3 failed silently. Langfuse confirmed only the successful call generated a trace. This suggests each server's stdio connection is managed independently and can fail independently — it's not a global lock.

[dnielso5]

my desktop app hasn't been able to read my filesystem for almost 3 days now.

The workaround from Reddit is to actually open the collapesed tool calls and they will go through:

https://www.reddit.com/r/ClaudeAI/comments/1qtspwj/claude_will_not_think_until_i_click_the_collapse/

Why the MCP is tied to the UI like that the world will never know.

I noticed that but it still fails over and over again trying to read the filesystem and eventually crashes and deletes the chat of what it was trying to do.

[DoMx]

my desktop app hasn't been able to read my filesystem for almost 3 days now.

The workaround from Reddit is to actually open the collapesed tool calls and they will go through:
https://www.reddit.com/r/ClaudeAI/comments/1qtspwj/claude_will_not_think_until_i_click_the_collapse/
Why the MCP is tied to the UI like that the world will never know.

I noticed that but it still fails over and over again trying to read the filesystem and eventually crashes and deletes the chat of what it was trying to do.

I'm the author of that Reddit thread. I haven't had a single failure on manually expanding the Tool tree to push the call through. What errors/behaviour are you seeing?