[BUG] Claude Desktop MCP tool calls hang until user clicks/expands panel

Same problem with Claude 1.1.1520 (48ced7) 2026-01-30T03:29:40.000Z

Can confirm this issue on Windows 11 with Claude Desktop v1.1.1520 (48ced7).

Additional findings from my testing:

Pattern discovered: The first MCP tool call in a new chat works fine. All subsequent calls hang until manually expanding the panel. This is 100% reproducible.

Affected (local stdio-based):

• Desktop Commander
• Windows-MCP
• Claude in Chrome

Not affected (remote HTTP-based):

• Todoist
• Google Calendar

This suggests the bug is specific to local stdio transport, not MCP in general. Remote HTTP integrations work without user interaction.

Tested with Claude Opus.

Additional diagnostic data — confirming server-side regression

Environment: macOS 15.5, Intel i7-1060NG7, 16GB RAM, non-admin user account (custom Homebrew in ~/brew)
MCP Extensions: Desktop Commander, Control Chrome, Control your Mac, PDF Tools (all via UtilityProcess/built-in Node)

Key finding: NOT a client-side bug

Downgraded from v1.1.1520 → v1.1.1200 (last version before the regression). Same blocking behavior persists. This confirms the issue is server-side (API/backend batching of tool_use blocks), not an Electron/client bug.

Blocking pattern observed

The hang specifically occurs with batched/grouped tool_use blocks — when the assistant response contains multiple tool calls, the UI renders them as a collapsed group requiring manual click to execute. Single tool calls sometimes auto-execute fine.

Side note / idea

Unrelated to the bug itself, but the current behavior made me think: a voluntary "step-by-step" mode where users can choose to manually approve each tool call could actually be a nice feature — as long as it's an opt-in toggle, not the default. Just an idea 🙂

Timeline from logs

MCP was working fine on Thu Jan 30 morning (pre-update). The auto-update to v1.1.1520 happened at 22:10 UTC+1 that evening:

22:10:29 — App starts, "Found an update, downloading"
22:10:47 — "Update downloaded and ready to install { releaseName: 'Claude 1.1.1520' }"
22:17:45 — App quits for update
22:18:19 — App restarts (new version)
22:18:28 — "Suspending MCP launch due to active quit" ← MCP servers fail to start
22:18:37 — "Uncaught ReferenceError: process is not defined" ← preload script crash
22:19:43 — "Main webview is unresponsive, will kill and reload"
22:19:45 — desktop_mcp_unexpected_close × 4 (all MCP servers killed)

App crash-looped 3 times before stabilizing. After that, MCP tool blocking started.

Additional client-side errors (may or may not be related)

From main-window.log:

[error] Unable to load preload script: .../mainWindow.js
[error] Uncaught ReferenceError: process is not defined

From main.log:

• 75× MaxListenersExceededWarning (EventEmitter leak on AutoUpdater) over 5 days
• 54× CSP violations blocking requests to a-api.anthropic.com

MCP server timing proof

From mcp.log, an edit_block call:

• Server responded in 168ms
• UI waited ~3 minutes for user to manually click/expand the tool panel

NVM interference (resolved, unrelated to core issue)

NVM was injecting its Node.js path into non-interactive shells used by Claude Desktop's UtilityProcess. Fixed with conditional loading in .zshrc:

[[ $- == *i* ]] && export NVM_DIR="$HOME/.nvm" && [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"

This resolved some MCP startup failures but did not fix the tool blocking/hanging issue.

Reproduction

100% reproducible on macOS. Every conversation with multiple MCP tool calls triggers the hang. Affects all MCP servers equally (Desktop Commander, Chrome Control, osascript, PDF Tools).

Impact & usage compensation request

Debugging this issue consumed 100+ tool calls and ~4 hours of a Pro subscription across multiple conversations — time and quota that should have been spent on actual project work. This is a significant impact for paying users relying on MCP for daily development workflows. We would appreciate Anthropic acknowledging this and considering usage limit compensation for affected users who spent their quota diagnosing an Anthropic-side regression.

---

That said — always happy to help with thorough bug reports. Thanks anyway for the amazing dev acceleration Claude Desktop provides on many tasks, even if R&D debugging remains as tricky with AI as it is for humans 😄

Additional Diagnostic: MCP Provider Approval Pattern (v0.0.37 vs v1.1.1520)

Test Environment: Claude Desktop v0.0.37 (stable downgrade) | macOS Sequoia | 3 MCP servers (Desktop Commander, Control your Mac, Claude in Chrome)

✅ Normal behavior (v0.0.37 - working)

Each MCP provider requires one approval click per conversation at first use:

| Provider | 1st call | Subsequent calls |
|----------|----------|-----------------|
| Desktop Commander | 🔒 click required | ✅ auto |
| Control your Mac (osascript) | 🔒 click required | ✅ auto |
| Claude in Chrome | 🔒 click required | ✅ auto |
| Internal tools (memory, search) | ✅ auto | ✅ auto |

Total clicks per conversation: 3 (one per MCP server, only on first use)

❌ Bug behavior (v1.1.1520 - regression)

Every single MCP tool call blocks and requires user click, even:

• Same provider, same conversation
• - Consecutive calls to the same tool
• - - After previous approval in the same session

Total clicks per conversation: N (one per tool call = completely unusable for autonomous workflows)

Key Distinction

The v1.1.1520 regression changed MCP approval from per-provider-per-conversation to per-call. This breaks any workflow requiring chained tool calls without human intervention (E2E testing, file analysis, code generation with multiple reads/writes, etc.).

<html><head></head><body><h1>Comparaison des Chats IA — Coups &amp; Debug</h1>
<h2>1. Vue d'ensemble des deux chats</h2>

  | Chat précédent (a9c97b04) | Chat actuel (logo V3)
-- | -- | --
Sujet principal | Debug MCP blocking + PDF fix + GitHub issue #22127 | Création logo Monwoo V3
Date | 2026-02-01 ~09h16–09h38 UTC | 2026-02-01 ~10h04+ UTC
Blocages utilisateur | ⛔ Multiples (clics manuels requis) | ✅ Aucun blocage
Providers MCP utilisés | Desktop Commander, Chrome, osascript, memory | bash_tool, view, create_file (conteneur)
Cause différence | Outils MCP macOS = 1 clic/provider/conversation | Outils conteneur Linux = pas de clic requis

<p><strong>Niveau 2 — Bug régression (v1.1.1520) :</strong>
CHAQUE appel MCP bloque, même après approbation précédente dans la même conversation. Rend les workflows autonomes impossibles.</p>
<h3>Workaround actuel — Stratégie "Designer IA" ✨</h3>
<p><strong>Découverte clé de ce chat :</strong> quand l'humain a besoin de s'absenter ou de ne pas être sollicité, basculer sur des tâches design/image/analyse qui utilisent exclusivement les outils conteneur Linux :</p>
<pre><code>Humain : "Améliore le logo / crée des variantes / ajuste les couleurs"
→ IA enchaîne 50+ coups autonomes (Python PIL, SVG, previews)
→ Humain revient quand il veut, feedback, relance
→ Zéro clic, zéro blocage, productivité maximale
</code></pre>
<p><strong>Autres tâches "mode autonome" possibles :</strong></p>
<ul>
<li>Génération de documentation (markdown, rapports)</li>
<li>Analyse de données (CSV, JSON via bash_tool)</li>
<li>Recherche web + synthèse</li>
<li>Création de présentations/spreadsheets</li>
<li>Refactoring de code dans le conteneur</li>
</ul>
<h3>Workarounds complémentaires</h3>
<p>Pour éviter les blocages dans les workflows de développement :</p>
<ol>
<li>
<p><strong>Utiliser les outils conteneur</strong> (<code>bash_tool</code>, <code>view</code>, <code>create_file</code>) pour tout ce qui ne nécessite pas d'accès macOS direct → <strong>0 blocage</strong> (comme prouvé dans ce chat logo)</p>
</li>
<li>
<p><strong>Utiliser Claude Code CLI</strong> pour les tâches nécessitant accès filesystem macOS → pas d'UI Claude Desktop, donc pas de blocage</p>
</li>
<li>
<p><strong>Grouper les appels MCP macOS</strong> en début de conversation pour déclencher les 3 clics d'approbation d'un coup, puis travailler en autonome</p>
</li>
</ol>
<h3>Solution demandée à Anthropic</h3>
<ul>
<li><strong>Toggle "Auto-approve MCP tools"</strong> dans Settings (comme Claude Code a ses modes Ask/Code/Plan)</li>
<li><strong>Compensation</strong> du temps/quota perdu sur le debug (~38 coups IA + 4h de travail)</li>
<li><strong>Documentation</strong> du comportement d'approbation MCP (actuellement non documenté)</li>
</ul>
<hr>
<h2>8. Preuve technique du bug</h2>
<p>Extrait des logs MCP montrant le décalage serveur vs UI :</p>
<pre><code>[mcp.log] edit_block call:

• Server response: 168ms
• UI wait for user click: ~3 minutes

</code></pre>
<p>Timeline de la régression :</p>
<pre><code>2026-01-30 matin → MCP fonctionne normalement
2026-01-30 22:10 → Auto-update v1.1.1520
2026-01-30 22:18 → Crash-loop (3×), MCP servers killed
2026-01-30 22:19+ → Blocage systématique MCP commence
</code></pre>
<p>Erreurs client associées :</p>
<ul>
<li>75× <code>MaxListenersExceededWarning</code> (EventEmitter leak)</li>
<li>54× CSP violations bloquant <code>a-api.anthropic.com</code></li>
<li><code>preload.js</code> crash: <code>ReferenceError: process is not defined</code></li>
</ul></body></html>

Additional observation: Pattern based on response structure (text vs. tool call order)

Environment: Windows 11, Claude Desktop v1.1.1520, multiple stdio-based MCP servers (Windows-MCP, Desktop Commander, Claude in Chrome)

I've observed a specific pattern that points to a client-side issue in the Desktop App, not a backend problem:

The pattern

| Response structure | Behavior |
|---|---|
| Tool call(s) first, then text | ✅ All tool calls execute automatically |
| Text first, then tool call(s) | ❌ Tool panel renders collapsed, blocks until manually expanded |
| Multiple tool calls without text between them | ✅ All execute automatically |
| Text → Tool call → Text → Tool call | ❌ Every tool call after text blocks |

Why this suggests a Desktop App issue

The order of content generation (text vs. tool call) determines whether the tool panel appears expanded or collapsed. When Claude generates text before making a tool call, the tool panel appears collapsed, and something in the app fails to trigger execution until the user manually expands it.

This is consistent with the January UI update that changed tool call display from tiles to collapsible rows.

Reproduction steps

1. Start a new chat with any local MCP server configured
2. Ask Claude something that makes it respond with text first, then use a tool
3. Observe: Tool panel appears collapsed, execution hangs
4. Ask Claude something that requires immediate tool use (no preamble text)
5. Observe: Tool executes automatically without interaction

Additional finding: Not related to Extended Thinking

I tested with "Extended Thinking" both enabled and disabled. The pattern remains identical:

• Thinking ON: Text before tool call → blocks
• Thinking OFF: Text before tool call → blocks
• Thinking OFF: Tool call first → executes automatically

This strongly suggests the issue is client-side in the Desktop App, not related to the Thinking feature or the Anthropic backend.

This pattern is 100% reproducible on my system.

Thank you everyone for the detailed bug report -> it helped us isolate the issue very quickly 🙏 . Have a fix merged and will be deployed first thing Monday. Closing this issue for now but if you are still seeing the issue on Monday, please tag me!

Thanks for the quick response and fix! 🙏

@alicelovescake still seeing the error. Version is unchanged from earlier reports: Claude 1.1.1520 (48ced7) 2026-01-30T03:29:40.000Z
No newer versions are available.

its monday and still broken...

@alicelovescake Still experiencing the issue on both Windows 11 and macOS (Apple Silicon). Current version: 1.1.1520. Restarted the app multiple times but no update arrived. Is the fix deployed yet?

✅ Confirmed FIXED for MacOs Claude app

Following up on my detailed diagnostic comments above — the issue is now resolved for MacOs Claude app.

Test performed today (2026-02-03):

| Provider | Tool tested | Result |
|----------|-------------|--------|
| Claude in Chrome | tabs_context_mcp | ✅ instant |
| Desktop Commander | list_directory | ✅ instant |
| Control your Mac | osascript | ✅ instant |

All 3 MCP providers responded without any blocking in a single conversation. The feature flag fix mentioned in #22451 appears to have resolved the issue for web users.

No need to upgrade claude app version, juste quit and relaunch.

Thank you @anthropic team for the quick turnaround! 🙏

---
Tested on macOS 15.5, Intel i7-1060NG7 — Monwoo development workflow

@alicelovescake Fix confirmed working on both Windows 11 and macOS. Thanks for the quick turnaround!

@alicelovescake Thanks for fixing the tool blocking issue! However, there's still a related UI transparency problem that remains unresolved.

Issue: Loss of Tool Call Visibility

While tool calls no longer hang, the UI has lost critical transparency features that existed in previous versions:

• Before: Users could see what Claude was about to do before tool execution (e.g., "going to replace this text with this text", tool parameters being passed)
• Now: The UI shows nothing until after an action is already completed
• Impact: No indication of what Claude is attempting to do, making MCP workflows unreliable and unsafe

This transparency was essential for:

• Trust and debugging
• Safe usage (knowing what will be modified before it happens)
• Understanding tool call failures when they occur

The current behavior removes the ability to see tool call intentions and parameters before execution, which was a valuable feature for MCP-based development workflows.

Could this UI transparency be restored in a future update? The previous behavior where users could see tool call details before execution was much more reliable for professional development use.

Related GitHub issues mentioning similar concerns:
https://github.com/anthropics/claude-code/issues/22319
https://github.com/anthropics/claude-code/issues/22451

@alicelovescake

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

Reopening the issue since I'm seeing a few more reports. We just released a new desktop version today Claude 1.1.1890 (af393c) 2026-02-03T21:05:53.000Z and on my side the tool calls from local servers (including Filesystem) happen without expanding.

For people still seeing the issue as of right now:

• are you using remote or local MCP?
• are you on chat, cowork or code?

@Sid1249, on your feedback for tool call visibility, you should still be able to see all the exact tool calls if you expand the section? i.e from the screenshot above

<img width="306" height="448" alt="Image" src="https://github.com/user-attachments/assets/9c7899ec-565f-456d-acc7-d3036a2e37c6" />

@alicelovescake Thanks for reopening and for the new desktop version!

Regarding your question about tool call visibility - yes, I can expand the section and see the tool calls, but there's a critical difference in timing and workflow compared to previous versions:

_Let's Take example of simple Edit File tool from file-system as in your screenshot_

Current Behavior (Post-Execution Only):

1. Tool executes completely first
2. Click to expand → See "F Edit file"
3. Click "Response" → See what it already did
4. Result: I can only review changes after they're already made to my files

Previous Behavior (Pre-Execution Visibility):

1. Tool call starts → Click to expand → Immediately showed parameters and intentions
2. I could see exactly what code Claude planned to write/replace
3. I could stop mid-execution if parameters looked wrong
4. Result: Prevention of destructive changes before they happened

The Key Problem:
The current 2-step UI workflow (expand → click Response) only shows me completed results, not intended actions. In previous versions, I had real-time visibility into what Claude was trying to do, which was critical for:

• Preventing wrong file edits before they execute
• Stopping tool calls with incorrect parameters mid-stream
• Safe professional development workflows

What Would Help:

1. Show tool call parameters immediately when execution starts (like before)
2. Single-click expansion to see what's happening/happened
3. Real-time visibility during execution, not just post-completion review

The current UI is great for reviewing completed work, but removes the safety net of seeing and potentially stopping problematic tool calls before they modify files.

Thanks for the suggestions and detailed description! Let me pass this feedback to the team that created this simplified view. Not within my control to change but I'll make sure your voice is heard

Feedback from real-world MCP usage (macOS Sequoia 15.3)

Environment:

• macOS Sequoia 15.3.1 (Apple Silicon M1)
• Claude Desktop App (latest)
• MCP Providers: Desktop Commander, Control your Mac, Claude in Chrome, PDF Tools

Current Status (Feb 4, 2026)

The MCP tool blocking bug is partially (or fully ?) resolved :

✅ Working:

• MCP tool calls now execute without manual panel expansion in most cases
• Desktop Commander commands execute immediately (~50-100ms)
• Sequential MCP calls work correctly

⚠️ Still problematic:

• Error "1FBQEUT" appears frequently, requiring Claude restart
• Occasional hangs still occur after 5-10 consecutive MCP calls
• The Claude Desktop App is less reliable than Claude Code CLI for heavy MCP workflows
• BUT : maybe not an issue today since may be related to yesterday afternoon fixes ? No Error "1FBQEUT" in current tchat for this github answer test.

Recommended Workaround

For autonomous/heavy MCP workflows, use Claude Code CLI (tested on Claude Code v2.1.31 Opus 4.5 · Claude Max) instead of Claude Desktop App:

# Autonomous mode - bypasses all permission prompts
claude --dangerously-skip-permissions "Your task here"

# With budget limit for safety
claude --dangerously-skip-permissions --max-budget-usd 5.00 "Task"

⚠️ Warning: This flag gives Claude full control (create/modify/delete files). Use in isolated environments with git backup.

Official documentation: https://code.claude.com/docs/en/cli-reference#cli-flags

Test Results (Feb 4, 2026 - 10:47 CET)

| Test | Result | Notes |
|------|--------|-------|
| Desktop Commander list_directory | ✅ OK | Immediate response |
| Desktop Commander start_process | ✅ OK | ~50ms execution |
| Desktop Commander get_file_info | ✅ OK | Immediate response |
| Sequential MCP calls (3+) | ✅ OK | All executed correctly |
| Long session (30+ min) | ⚠️ Flaky | Error 1FBQEUT appears |

Suggestions

1. Investigate the "1FBQEUT" error code - seems related to session corruption (ou yesterday bugs, seen yesterday afternoon (Paris FR time), but was ok in the morning, is ok this morning, no error for current test result).
2. Consider adding automatic session recovery when this error occurs
3. Document Claude Code CLI as official workaround for heavy MCP workflows
4. ⚠️ Small diff between Claude Desktop and Claude Code : Claud code will stop ALL process and detached process it did start if you press 'ESC', but Claude Desktop do not stop all process and detached process when we call stop (ex : long e2e testing commands are still running if I click the stop in Claude Desktop, but all is finished directly in Claude code, more adapted to e2e testings. Add a Soft/Hard stop to Claude Desktop ?)

---

📊 Investigation Costs (transparency)

| Resource | Value |
|----------|-------|
| AI Tokens (Input) | ~30K tokens |
| AI Tokens (Output) | ~15K tokens |
| Human Time | ~25 min (review, validation, testing) |
| Session Duration | ~30 min total |

Costs shared for transparency - helps estimate real-world debugging effort.

---

Tested by: @claude-dev-monwoo (Miguel / Monwoo)
MCP config: Multiple providers (Desktop Commander, Control your Mac, Claude in Chrome, PDF Tools)

Feedback from real-world MCP usage (macOS Sequoia 15.3)

Environment:

• macOS Sequoia 15.3.1 (Apple Silicon M1)
• Claude Desktop App (latest)
• MCP Providers: Desktop Commander, Control your Mac, Claude in Chrome, PDF Tools

Current Status (Feb 4, 2026)

The MCP tool blocking bug is partially (or fully?) resolved:

✅ Working:

• MCP tool calls now execute without manual panel expansion in most cases
• Desktop Commander commands execute immediately (~50-100ms)
• Sequential MCP calls work correctly

⚠️ Still problematic:

• Error "1FBQEUT" appears frequently, requiring Claude restart
• Occasional hangs still occur after 5-10 consecutive MCP calls
• The Claude Desktop App is less reliable than Claude Code CLI for heavy MCP workflows
• BUT: this might not be an issue today since it may be related to yesterday afternoon's fixes. No Error "1FBQEUT" in the current chat for this GitHub answer test.

Recommended Workaround

For autonomous/heavy MCP workflows, use Claude Code CLI (tested on Claude Code v2.1.31 Opus 4.5 · Claude Max) instead of Claude Desktop App:

# Autonomous mode - bypasses all permission prompts
claude --dangerously-skip-permissions "Your task here"

# With budget limit for safety
claude --dangerously-skip-permissions --max-budget-usd 5.00 "Task"

⚠️ Warning: This flag gives Claude full control (create/modify/delete files). Use in isolated environments with git backup.

Official documentation: https://code.claude.com/docs/en/cli-reference#cli-flags

Test Results (Feb 4, 2026 - 10:47 CET)

| Test | Result | Notes |
|------|--------|-------|
| Desktop Commander list_directory | ✅ OK | Immediate response |
| Desktop Commander start_process | ✅ OK | ~50ms execution |
| Desktop Commander get_file_info | ✅ OK | Immediate response |
| Sequential MCP calls (3+) | ✅ OK | All executed correctly |
| Long session (30+ min) | ⚠️ Flaky | Error 1FBQEUT appears |

Suggestions

1. Investigate the "1FBQEUT" error code - seems related to session corruption (or yesterday's bugs, seen yesterday afternoon Paris FR time, but was OK in the morning, is OK this morning, no error for current test result).
2. Consider adding automatic session recovery when this error occurs
3. Document Claude Code CLI as official workaround for heavy MCP workflows
4. ⚠️ Small difference between Claude Desktop and Claude Code: Claude Code will stop ALL processes and detached processes it started if you press 'ESC', but Claude Desktop does not stop all processes and detached processes when we call stop (e.g.: long e2e testing commands are still running if I click stop in Claude Desktop, but everything stops directly in Claude Code, more suited for e2e testing. Add a Soft/Hard stop to Claude Desktop?)
5. Claude Code allows sending additional requests without having to press 'ESC' (roughly equivalent to the stop button in Claude Desktop macOS App). Could we have a 'comment' button in addition to the multi-stop button for the same feature as Claude Code, please?)

---

📊 Investigation Costs (transparency)

| Resource | Value |
|----------|-------|
| AI Tokens (Input) | ~30K tokens |
| AI Tokens (Output) | ~15K tokens |
| Human Time | ~25 min (review, validation, testing) |
| Session Duration | ~30 min total |

Costs shared for transparency - helps estimate real-world debugging effort.

---

Tested by: @claude-dev-monwoo (Miguel / Monwoo)
MCP config: Multiple providers (Desktop Commander, Control your Mac, Claude in Chrome, PDF Tools)

Closing for now — this doesn't appear to be about Claude Code. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.