### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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? The MCP permission dialog becomes actionable while the tool call it describes is still being generated. If "Allow once" is clicked at that point, the call

[BUG] Claude Desktop - MCP tool call hangs silently if "Allow once" is clicked before Claude finishes generating the call

Status Open

Maintainer reply None cached

Activity 0 comments · opened Sep 4, 2026

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?

The MCP permission dialog becomes actionable while the tool call it describes is still being generated. If "Allow once" is clicked at that point, the call is never transmitted to the MCP server. There is no error, no second prompt, and no indication that anything is wrong: the conversation simply stalls until it reports No result received from the Claude Desktop app, roughly four minutes later. The call has no effect — no partial write, and no entry in the server-side log. Subsequent calls work normally, so the server process is healthy.

While the call is still streaming, the dialog displays what appears to be a complete, well-formed request — in one observed case a Filesystem write showing a path parameter, no content parameter, and a closing brace. It seems that the incomplete JSON is repaired for display, and there is nothing on screen to indicate that the request is unfinished or that approving it now is unsafe.

Waiting for generation to finish before clicking "Allow once" makes the same call succeed immediately.

This is independent of argument size, tool type, MCP server and platform. Argument size does however vary how long generation takes, and therefore how likely a user is to click during the window — which is why I initially believed the failure to be dependent on a size threshold (believed to be around 500 B–1.1 KB of arguments, i.e. what could stream in the short time between when the dialog appears and when it is clicked). A ~300 B call that succeeds consistently when approved after generation completes fails in exactly the same way when approved during it.

What Should Happen?

Any of the following would be an improvement over a silent stall:

The permission dialog should not be actionable until the tool call is fully generated.
Failing that, an approval granted mid-generation should apply to the completed call.
Failing that, the mismatch should re-prompt, or at minimum surface an explicit error rather than hanging until timeout.

Error Messages/Logs

Error

No result received from the Claude Desktop app after waiting 4 minutes. The local MCP server providing this tool may be unresponsive, crashed, or not running. Further calls to this tool are likely to time out the same way; consider using an alternative approach or ask the user to restart their local MCP servers.

Steps to Reproduce

Configure any MCP server with a tool taking a string argument. The Filesystem connector from Customize → Connectors → Discover is sufficient; no third-party server is needed.
Set the tool to "Requires permission".
Ask Claude to call it with a few kilobytes of argument content, so that generation takes a second or two.
Click "Allow once" as soon as the dialog appears, while the call is still streaming. → The click is accepted, then nothing happens. The call eventually times out with "No result received from the Claude Desktop app".
Repeat, but wait until generation has visibly finished before clicking "Allow once". → Succeeds.

The same contrast reproduces with arguments as small as ~300 B, given a click fast enough to land during generation.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.44121.4.0 (Claude Desktop)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

[!IMPORTANT] The form allows for only one platform to be selected, but this bug was reproduced on both Windows and Linux.

[!NOTE] The majority of this report was generated by Claude (Opus 5) based on my findings, before being edited by me. I have ensured that everything accurately represents the issue I encounderd and the results of my tests.

Related observations

"Always allow" is unaffected, whether set in the connector's tool settings or chosen from the button in the dialog.
Leaving the dialog untouched for over four minutes results in the call timing out on its own, before any click.
Reproduced on three independent MCP servers: the first-party Filesystem connector, mcp-remote bridging to an in-Obsidian HTTP server on 127.0.0.1:27200, and a standalone gitea-mcp binary.
Reproduced on both Windows 11 and Kubuntu 26.04.
With the Obsidian MCP server, an equivalent 3 KB payload POSTed directly from PowerShell, bypassing Claude Desktop, completed in 56 ms and took effect.

Possibly related

#80012 reports the same user-visible symptom — a four-minute No result received from the Claude Desktop app timeout on a call the server never sees — and hypothesises that in-flight calls are bound to a handler instance rather than to a persistent per-call routing table. That report describes an intermittent, concurrency-triggered failure that also loses responses on the way back from a server that completed the call, which is not what happens here: the failure described above is deterministic, occurs in a single conversation with no concurrency, and never reaches the server at all. The two may share a cause in the approval/dispatch layer — that report notes per-call identity already exists as toolId in tool_approval_gate log entries — but the triggers are different, so this is filed separately.

Environment

Claude Desktop (Windows): 1.44121.4.0
OS (Windows): Windows 11 Pro 21H2
Claude Desktop (Linux): 1.40609.1, official build from Anthropic's APT repository per <https://code.claude.com/docs/en/desktop-linux>
OS (Linux): Kubuntu 26.04
MCP servers used:
Filesystem connector (from Discover);
mcp-remote → MCP Connector plugin for Obsidian v2.4.0 on 127.0.0.1:27200 (GitHub repository);
gitea-mcp (stdio) (Gitea repository)

View original on GitHub ↗