[BUG] Claude Desktop MCP permission prompt pauses stdio read loop causing pipe buffer backpressure deadlock under heavy session load

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?

When an MCP connector permission is set to "Ask Each Time," Claude Desktop pauses its stdio read loop while waiting for the user to respond to the permission prompt. Under heavy session load, the MCP server continues writing to stdout during that pause, filling the macOS pipe buffer (~64KB). Once full, the server's next write blocks indefinitely — a classic backpressure deadlock. After 4 minutes, Claude Desktop fires a timeout error. The MCP server process then becomes permanently unresponsive, persisting across Claude Desktop restarts and full Mac restarts.

This bug is not in any MCP connector. The failure occurs entirely within Claude Desktop's permission prompt handling layer, before the request ever reaches the MCP server. The MCP server log shows zero record of the failed calls, confirming the server never receives the timed-out requests.

What Should Happen?

Claude Desktop should continue draining the MCP server's stdout pipe independently of the permission prompt UI. The permission prompt should not block the stdio read loop. If the prompt times out, Claude Desktop should return a clean descriptive error to the user and automatically recover the MCP server process — without requiring a manual pkill or restart.

Error Messages/Logs

Claude Desktop error returned to user:
"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."

During failing sessions, MCP server log shows only initialize/shutdown sequences with zero tool calls recorded — confirming the server never received the timed-out requests:

2026-04-12T02:07:43.679Z [apple-notes-advanced] [info] Server started and connected successfully
2026-04-12T02:59:12.045Z [apple-notes-advanced] [info] Server transport closed (intentional shutdown)

No tool calls appear between server start and shutdown — the deadlock is invisible at the server layer.

Successful session after Always Allow fix applied (for comparison):

2026-04-13T14:17:52.190Z [apple-notes-advanced] [info] Message from client: {"method":"tools/call","params":{"name":"update_note"...
2026-04-13T14:17:55.399Z [apple-notes-advanced] [info] Message from server: {"result":{"content":[{"type":"text","text":"Note updated successfully..."}]}}

Steps to Reproduce

Reproduction requires a heavy session context — not a clean setup:

1. Use a Claude Desktop chat window with weeks of conversation history and multiple active MCP connectors
2. Set any MCP connector permission to "Ask Each Time"
3. Trigger a tool call on that connector
4. Observe: the permission prompt appears but times out silently after 4 minutes — Claude Desktop returns "No result received from the Claude Desktop app after waiting 4 minutes"
5. Attempt additional calls — same timeout error repeats
6. Restart Claude Desktop — issue persists
7. Restart the Mac — issue persists
8. Run pkill -f "<mcp-server-process>" in Terminal — temporarily restores function, but deadlock recurs on the very next call
9. Set the connector permission to "Always Allow" — resolves the issue completely and permanently

Control test confirming backpressure hypothesis:

• Always Allow applied: 4 consecutive tool calls succeeded reliably
• Always Allow removed: deadlock on first call
• Always Allow reapplied: confirmed working

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

N/A — this bug is in Claude Desktop, not Claude Code CLI. Filed here as there is no public Claude Desktop issue tracker.

Claude Code Version

Claude Desktop: claude-ai v0.1.0

Platform

Other

Operating System

macOS

Terminal/Shell

Other

Additional Information

Discovery, research, and testing credit: @CarlosFMeneses. Testing was conducted on the apple-notes-advanced connector by @ailenshen, referenced in ailenshen/apple-notes-mcp#5 and ailenshen/apple-notes-mcp#6. The pipe buffer backpressure mechanism was independently corroborated by community member @m13v.

Related but different issue in this repository: #36319 (Claude Desktop drops MCP stdio calls when argument payload exceeds ~1KB — same stdio layer, different mechanism)

Connector affected: apple-notes-advanced (@ailenshen/apple-notes-mcp@latest)
Permission setting at time of failure: Ask Each Time

Suggested fixes:

1. Do not pause the stdio read loop during permission prompts — drain the pipe independently of the permission UI to prevent backpressure buildup
2. Graceful timeout handling — return a clean descriptive error to the user rather than silently deadlocking
3. Log the timeout event at the Claude Desktop layer — currently the crash is completely invisible in the MCP server log
4. Dynamic timeout threshold — adjust based on session resource load rather than a fixed value
5. Auto-recover the MCP server process — after a permission timeout the server should recover automatically without requiring manual pkill or restart
6. Visual feedback — show the user that a permission prompt is pending rather than silently failing after 4 minutes