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

[Rangard78]

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?

Claude Desktop UI does not render MCP tool results until user manually clicks/expands the "Used [MCP Server] integration" panel.

The MCP server completes execution immediately (~75ms verified via logs), but the UI appears frozen indefinitely. Conversation cannot proceed until user interacts with the collapsed tool panel.

Tested on both macOS and Windows with multiple MCP servers (Desktop Commander, Playwright, Memory) - all affected.

What Should Happen?

MCP tool results should render automatically when the server returns response. UI should update without requiring user interaction. Claude should continue its response immediately after receiving tool results.

Error Messages/Logs

No error messages - UI simply freezes/waits.

Server logs confirm immediate completion:
2026-01-31T09:20:24.384Z [Desktop Commander] Tool call started
2026-01-31T09:20:24.459Z [Desktop Commander] Message from server: {"result":{"content":[...]}}

Execution time: ~75ms
User waited: 20+ seconds (no update)
After clicking panel: Result appeared immediately

Steps to Reproduce

1. Start Claude Desktop with any MCP server configured
2. Ask Claude to perform any MCP operation (e.g., "list my desktop files")
3. UI shows "Used [MCP Server] integration" in collapsed state
4. Do NOT click on the panel - just wait
5. Observe: UI appears stuck indefinitely (tested 30+ seconds)
6. Click/expand the "Used [MCP Server] integration" panel
7. Observe: Result appears almost immediately, conversation continues

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

29.01.2026

Claude Code Version

N/A - This is Claude Desktop bug, not Claude Code

Platform

Other

Operating System

macOS

Terminal/Shell

Other

Additional Information

• 100% reproducible on both macOS (Apple Silicon) and Windows 11
• Affects ALL MCP servers, not specific to one
• Issue appeared around January 30, 2026
• Same MCP servers work correctly in Claude Code CLI (no freeze)
• This is a Claude Desktop UI issue, not MCP server issue

[massdo]

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

[David9067]

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.

[claude-dev-monwoo]

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 😄

[claude-dev-monwoo]

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

[claude-dev-monwoo]

Comparaison des Chats IA — Coups & Debug

1. Vue d'ensemble des deux chats

	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

Niveau 2 — Bug régression (v1.1.1520) : CHAQUE appel MCP bloque, même après approbation précédente dans la même conversation. Rend les workflows autonomes impossibles.

Workaround actuel — Stratégie "Designer IA" ✨

Découverte clé de ce chat : 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 :

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

Autres tâches "mode autonome" possibles :

• Génération de documentation (markdown, rapports)
• Analyse de données (CSV, JSON via bash_tool)
• Recherche web + synthèse
• Création de présentations/spreadsheets
• Refactoring de code dans le conteneur

Workarounds complémentaires

Pour éviter les blocages dans les workflows de développement :

1. Utiliser les outils conteneur (bash_tool, view, create_file) pour tout ce qui ne nécessite pas d'accès macOS direct → 0 blocage (comme prouvé dans ce chat logo)

2. Utiliser Claude Code CLI pour les tâches nécessitant accès filesystem macOS → pas d'UI Claude Desktop, donc pas de blocage

3. Grouper les appels MCP macOS en début de conversation pour déclencher les 3 clics d'approbation d'un coup, puis travailler en autonome

Solution demandée à Anthropic

• Toggle "Auto-approve MCP tools" dans Settings (comme Claude Code a ses modes Ask/Code/Plan)
• Compensation du temps/quota perdu sur le debug (~38 coups IA + 4h de travail)
• Documentation du comportement d'approbation MCP (actuellement non documenté)

---

8. Preuve technique du bug

Extrait des logs MCP montrant le décalage serveur vs UI :

[mcp.log] edit_block call:
  - Server response: 168ms
  - UI wait for user click: ~3 minutes

Timeline de la régression :

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

Erreurs client associées :

• 75× MaxListenersExceededWarning (EventEmitter leak)
• 54× CSP violations bloquant a-api.anthropic.com
• preload.js crash: ReferenceError: process is not defined

[David9067]

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.

[alicelovescake]

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!

[Rangard78]

Thanks for the quick response and fix! 🙏

[opcode81]

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