[BUG] Claude Desktop 1.569.0 macOS — "Claude's response could not be fully generated" when a single turn involves multiple stdio MCP tool calls

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?

In a single conversation turn, if Claude attempts 3 or more sequential tools/call requests to a stdio MCP server, Claude Desktop drops with "Claude's response could not be fully generated" and a brief network error notification in the top right corner. The failure is consistent and reproducible regardless of payload size — it triggers even with minimal commands (~150 bytes serialized). The MCP server, daemon, and transport are all healthy throughout.

This is distinct from the payload-size bug reported in #36319 (Windows, argument size threshold). This is a per-turn tool call count failure on macOS.

Evidence that MCP is not the cause

• mcp-server-*.log shows all tool calls succeeding and returning results normally
• mcp.log shows no disconnects, transport closures, or errors
• main.log does not log the failure at all — completely silent
• The MCP server process keeps running normally after the drop
• Starting a fresh conversation immediately works again

What Should Happen?

A single conversation turn should support as many sequential MCP tool calls as needed without dropping response generation. The error should not occur when the MCP server is responding correctly to every request.

Error Messages/Logs

UI: "Claude's response could not be fully generated" with a brief network error notification.

mcp-server-*.log: All tool calls succeed and return results normally. No errors.

mcp.log: No disconnects, transport closures, or errors of any kind.

main.log: Completely silent about the failure. Last entries are routine startup/sync logs. The drop is never logged.

main.log startup warnings present on every launch:
[warn] [CCD] Shell environment extraction failed, using process.env: Error: Utility process exited with code: 1
[warn] UtilityProcess Check: Extension cortex not found in installed extensions
(last warning repeats for every configured stdio MCP server)

Steps to Reproduce

1. Configure a stdio MCP server in claude_desktop_config.json with a single tool that executes commands
2. Start Claude Desktop and open a new conversation
3. In a single message, ask Claude to run that tool 3 or more times sequentially (e.g. "check X, then check Y, then check Z")
4. Observe: first 1-2 tool calls complete and return results successfully
5. Claude Desktop then drops with "Claude's response could not be fully generated"
6. Check mcp-server-*.log, mcp.log, and main.log — no error appears in any log
7. Open a fresh conversation and repeat the same request — it may succeed, then fail again on the next multi-call turn

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Approximately two versions prior to 1.569.0 (exact version not recorded)

Claude Code 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 Desktop version: 1.569.0

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

• macOS arm64, Apple Silicon
• MCP server: custom stdio server, Node.js v18.20.7, @modelcontextprotocol/sdk 1.27.1
• The MCP server daemon continues running and responding normally after the drop
• Starting a fresh conversation immediately works — confirming the MCP transport itself is not broken
• The failure appears to be in Claude Desktop's response generation loop, not the stdio transport
• Related prior report: #36319 (silent drop on Windows, attributed to payload size >1KB, dismissed as invalid). This reproduction on macOS uses payloads well under 1KB, suggesting the root cause may be broader — a per-turn tool call count limit or generation-side timeout rather than a transport write limit.
• Workaround: start a new conversation for each multi-step task