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

Same as

https://github.com/anthropics/claude-code/issues/22299
and
https://github.com/anthropics/claude-code/issues/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.

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

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

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.

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!

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?

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.

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.

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

> > 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?

> > > 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?

<img width="1101" height="1070" alt="Image" src="https://github.com/user-attachments/assets/ca3393fe-5c45-40e8-89d2-5d6ec356ec9a" />

Thank you everyone for the report! We turned off a feature flag that was potentially causing the issue. Can you try again and see if it's working?

Really apologize for the disruption and appreciate you guys for taking the time to issue!

✅ Confirmed FIXED for Claude Desktop app — macOS

Following the feature flag fix mentioned by @alicelovescake, I can confirm the issue is resolved for Claude Desktop app on macOS.

Test Environment

• Platform: macOS 15.5, Intel i7-1060NG7, 16GB RAM
• Interface: Claude Desktop app (macOS native)
• MCP Servers: Desktop Commander, Control your Mac, Claude in Chrome, PDF Tools
• Date: 2026-02-03 ~05:45–06:00 UTC (~15 min session)

Test Results (this conversation)

| # | Provider | Tool tested | Result |
|---|----------|-------------|--------|
| 1 | Desktop Commander | list_directory | ✅ instant |
| 2 | Control your Mac | osascript | ✅ instant |
| 3 | Claude in Chrome | tabs_context_mcp | ✅ instant |
| 4 | Linux Container | bash_tool | ✅ instant |
| 5 | Desktop Commander | get_file_info | ✅ instant |
| 6 | Control your Mac | osascript (2nd call) | ✅ instant |

Conversation Statistics — Tool Calls Audit

| Category | Count |
|----------|-------|
| conversation_search | 2 |
| Desktop Commander calls | ~15 |
| Control your Mac (osascript) | ~8 |
| Claude in Chrome calls | ~12 |
| bash_tool (container) | ~4 |
| web_search | 2 |
| Total tool calls | ~50+ |
| User blocking clicks | 0 |
| Human wait time | 0 min |

Comparison: Before vs After Fix

| Metric | Before fix (2026-02-01) | After fix (2026-02-03) |
|--------|------------------------|------------------------|
| Tool calls | ~60 | ~50+ |
| Productive % | 33% | 100% |
| Human clicks required | 5-8 | 0 |
| Human wait time | ~24 min | 0 min |
| AI moves wasted on blocking | ~38 (~40%) | 0 |
| App restarts needed | 1 | 0 |

Human Time Cost Analysis

| Segment | Duration | Activity |
|---------|----------|----------|
| 05:45-05:50 | 5 min | Initial test + conversation_search context loading |
| 05:50-05:55 | 5 min | Navigate to #22127, scroll, review comments |
| 05:55-06:00 | 5 min | Navigate to #22451, test MCP tools, draft comment |
| Total | ~15 min | 100% productive (vs ~45 min with blocking before) |

Note

This confirms the fix works for Claude Desktop app on macOS. Windows users may want to confirm separately.

Thank you @anthropic team for the quick turnaround on the feature flag fix! 🙏

---
Tested via Monwoo development workflow — Full diagnostic report in #22127

@Anthropic

For MacOS Desktop App:

<img width="106" height="59" alt="Image" src="https://github.com/user-attachments/assets/6d27b68e-669a-4f69-8635-c1b9ef61e8bb" />

<img width="153" height="224" alt="Image" src="https://github.com/user-attachments/assets/cae19bf0-568a-4316-93c8-5f148aa94250" />

Filesystem tools > e.g. Edit file still gets stuck until click and expand.

Affected Tools:
read_file
read_text_file
read_multiple_files
write_file
edit_file
create_directory
list_directory
list_directory_with_sizes
directory_tree
move_file
search_files
get_file_info
list_allowed_directories
Copy file to Claude

Claude Desktop for Windows MCP Server has issues, often caused by stdout not being captured in sub-processes.
This causes stalls and forces Claude to retry using different approaches (PowerShell, CMD.EXE, redirecting stdout to temp file, etc).
In addition, Windows MCP is quite verbose and clogs the context window.
The solution I found is to give Claude access to the Unix toolset, which is included in GIT for Windows.
This speeds Claude up significantly, uses less context and works better, as Claude 'prefers' Linux.
The implementation is an MCP server, 45 LOC, 2-minute install, you can delete Windows MCP.

git_bash_mcp.py
README.md

Thank you everyone for the report! We turned off a feature flag that was potentially causing the issue. Can you try again and see if it's working? Really apologize for the disruption and appreciate you guys for taking the time to issue!

The fix initially worked after the above message was posted, but the issue is back this morning on MacOS.
Same symptoms - verbose granular output, fails simple read/right/modify/move tools unless expanded, slow implementation, poor user experience etc.
Can this issue/bug be reopened?

Another possibly related consequence is that in the middle of this, if it does compaction, it restarts its entire thread as if it forgot everything.

@pratik-pednekar what MCP are you using? I just tested with FIlesystem MCP in the chat tab and seemed to work without expanding. can you give me any details on repro steps?

Hi Alicelovescake,

There are (for some reason) two filesystems (Filesystem (desktop) and filesystem (local dev)).

<img width="1146" height="723" alt="Image" src="https://github.com/user-attachments/assets/a299e9f6-0291-408e-bbe7-8a7f6efa758a" />

COnfiguring the local dev version looks like this (i believe I might have 2 MCPs, one claude and one added extension). Is this causing the issue. Any guidance on which is more suitable for working with local files?

<img width="1140" height="662" alt="Image" src="https://github.com/user-attachments/assets/1ba50e74-9e27-4d8e-8636-a24f9a1051a2" />

Thanks for the support.

PS - the issue seems to not be there today, but the file access etc. appear to be slower. There seems to be a max compaction message (possibly unrelated issue)

Pratik

If your Claude Desktop MCP tools hang for 5 minutes and fail with 'No result received', the stdio pipe is being blocked by a collapsed UI element. There's a simple workaround involving the tool call boxes in the chat interface: https://cacheoverflow.dev/blog/KMdWLYK9

Thanks for the report. The Desktop hang was traced and the fix shipped in February. The "expand the tool box to unblock it" workaround a few of you found lines up with the cause. Closing this; please reopen if you still see the 5-10 minute hang on a current Desktop build.