[BUG] MCP tool_result delivery corrupts SSE streaming connection, causing TypeError: network error and conversation data loss on every tool call

[computerdab]

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?

MCP tool call results corrupt the SSE streaming connection, causing TypeError: network error on every tool invocation and wiping entire conversations from history without recovery. The issue is 100% reproducible: every single call to an MCP tool that executes a shell command triggers a network stream failure in the Claude Desktop client. After a cluster of 4 to 6 calls the failure escalates to message_store_sync_loss_accepted, permanently destroying the conversation with no way to recover it. This regression was not present approximately two app versions ago.

What Should Happen?

MCP tool calls should complete and return their result while the streaming SSE connection to api.anthropic.com remains fully stable. The conversation history should be preserved before, during, and after any number of tool call round-trips. The user should be able to invoke MCP tools repeatedly in a session without any risk of conversation data loss.

Error Messages/Logs

Error Messages/Logs
Extracted verbatim from ~/Library/Logs/Claude/claude.ai-web.log on 2026-04-04. The following cluster repeats for every single MCP tool call across the entire session (16 occurrences today alone):
2026-04-04 16:39:12 [error] [COMPLETION] Request failed TypeError: network error
2026-04-04 16:39:12 [error] [COMPLETION] Not retryable error, throwing
2026-04-04 16:39:12 [error] [COMPLETION] Non-API stream error TypeError: network error
2026-04-04 16:39:12 [error] Uncaught (in promise) TypeError: network error
2026-04-04 16:39:16 [error] [COMPLETION] Failed all attempts to invalidate conversation tree with consistency=eventual [object Object]
2026-04-04 16:39:17 [warn]  [COMPLETION] message_store_sync_blocked [object Object]
Two separate occurrences escalated to full conversation destruction:
2026-04-04 17:50:48 [warn]  [COMPLETION] message_store_sync_loss_accepted [object Object]
2026-04-04 18:11:33 [warn]  [COMPLETION] message_store_sync_loss_accepted [object Object]
Total in claude.ai-web.log today: 37 network errors, 2 conversation wipe events.
Cross-referencing mcp-server-cortex.log (which timestamps in UTC, local timezone is UTC-3) confirms that every single network error fires at the exact moment a tool result is returned from the MCP server. Zero errors occur during idle periods. The most direct example: an MCP tool ran echo ok via SSH, completed in under 2 seconds, and triggered TypeError: network error at the precise millisecond the result arrived. This rules out timeout as the sole cause. The corruption occurs at result delivery, not during execution.

Steps to Reproduce

1. Install Claude Desktop v1.569.0 on macOS (arm64).
2. Configure any MCP server that exposes a tool executing shell commands via child_process.spawn over stdio transport. The MCP server must use @modelcontextprotocol/sdk and communicate via stdin/stdout.
3. Start a new conversation in Claude Desktop.
4. Ask Claude to use the MCP tool to run any command, including trivially simple ones (e.g., echo hello, git status, ls).
5. Observe that ~/Library/Logs/Claude/claude.ai-web.log immediately logs TypeError: network error and Failed all attempts to invalidate conversation tree with consistency=eventual.
6. Repeat the tool invocation 3 to 5 more times in the same conversation.
7. Observe message_store_sync_loss_accepted — the entire conversation disappears from Claude Desktop with no recovery option.

No specific project, code, or repository is required. Any MCP server with a command-execution tool reproduces this immediately and consistently.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

1.569.0 (darwin, arm64, Node 24.14.0)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

This bug has a direct financial impact. Each destroyed conversation contains work performed against the Anthropic API. Tokens are consumed and billed during the session. When the conversation is wiped by message_store_sync_loss_accepted, all context, tool results, and progress are permanently lost. The user must start over, re-consuming tokens for the same work. On a heavy development day (274 MCP tool calls logged today), this represents substantial wasted spend on a Team subscription.
The regression aligns with a recent Claude Desktop update. Prior versions of the app handled MCP tool call round-trips without any streaming disruption.
A note that may assist the engineering team: a recent Claude Code release added CLAUDE_STREAM_IDLE_TIMEOUT_MS to configure the streaming idle watchdog threshold, defaulting to 90 seconds. It is possible the same watchdog is active in Claude Desktop's streaming layer and is being triggered not by idleness but by the act of flushing a tool_result chunk — particularly for tool calls that involve subprocess execution and produce buffered output. The corruption consistently fires at result delivery rather than during execution, which points to a flush, chunk framing, or connection state management issue introduced in a recent build.
Full log files attached here:

~/Library/Logs/Claude/claude.ai-web.log
~/Library/Logs/Claude/mcp-server-cortex.log
~/Library/Logs/Claude/main.log

claude.ai-web.log

mcp-server-cortex.log

main.log

[github-actions]

Found 3 possible duplicate issues:

1. [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 #43642
2. [BUG] MCP Proxy: SSE stream repeatedly drops with 409 Conflict, reconnection fails #31752
3. [BUG] MCP proxy silently hangs on tool_use results — Claude CLI blocks waiting for complete tool_result set #38437

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[computerdab]

This is not a duplicate of any of the three referenced issues.

vs #43642 (listed as duplicate of itself): #43642 is my own related issue filed the same day. They describe different failure modes. #43642 is triggered by a per-turn call count threshold (3+ sequential calls, partial success before crash, fresh conversation sometimes recovers). This issue (#43676) triggers on every single tool call regardless of count, produces 37 network errors in a single session, and in 2 separate occurrences escalated to message_store_sync_loss_accepted with permanent conversation destruction. Different trigger, different severity, different failure path.

vs #31752 (SSE stream drops with 409 Conflict): The failure in #31752 is an HTTP 409 status code during SSE reconnection. My error is TypeError: network error firing at result delivery, not during reconnection. The transport corruption happens at the moment a tool_result chunk is flushed, confirmed by millisecond-level timestamp cross-correlation between mcp-server-cortex.log (UTC) and claude.ai-web.log. No HTTP 409 appears anywhere in my logs.

vs #38437 (proxy silently hangs on tool_use results): A hang means the process stalls waiting for a response that never arrives. My bug is the opposite: the error fires immediately and noisily at result delivery. The conversation destruction (message_store_sync_loss_accepted) also has no equivalent in a hang scenario.

Supporting evidence attached to the original report: claude.ai-web.log, mcp-server-cortex.log, and main.log, with 37 network errors and 2 conversation wipe events recorded today alone. This is a regression in Desktop v1.569.0 not covered by any of the three referenced issues.

[computerdab]

---

Update: DevTools trace and HAR analysis confirm client-side stream teardown

Following guidance from Anthropic support, I enabled DevTools on Claude Desktop (allowDevTools: true in developer_settings.json) and captured a full Network + Console trace during a reproducible failure session. The HAR file was exported and analyzed. Here is what the data shows.

---

Test setup

• Claude Desktop 1.569.0, macOS arm64, Apple Silicon

• 6 stdio MCP servers configured, including a custom Cortex server that executes shell commands via child_process.spawn

• Reproduction prompt: asked Claude to run echo hello, then echo world, then echo done in a single turn

• DevTools Network tab open with Preserve log enabled throughout

---

HAR analysis: 4 POST completion requests captured

The HAR recorded every network request during the failing session. There were 4 POST requests to the completion endpoint for the conversation that failed:

| Endpoint | HTTP Status | Response size | Time

-- | -- | -- | -- | --
1 | /completion | 200 OK | 0 bytes | 2,950ms
2 | /completion | 200 OK | 0 bytes | 5,937ms
3 | /retry_completion | 200 OK | 0 bytes | 16,711ms
4 | /retry_completion | 200 OK | 14,091 bytes | 29,273ms

Requests 1, 2, and 3 each received HTTP 200 from the server and then delivered zero bytes before the connection was reset (net::ERR_CONNECTION_RESET). Request 4 eventually succeeded after 29 seconds, returning a complete SSE stream ending with message_stop.

This pattern proves the server was healthy and accepting requests throughout the entire session. The failure is not a server-side rejection. The failure is not a payload size issue (the commands are trivially small). The failure is not a timeout during tool execution. The SSE stream is being torn down inside the Claude Desktop renderer process immediately after the 200 header is received, before a single event byte is delivered.

---

Console trace at the moment of failure

The following cluster appeared in DevTools Console on every failing request, corroborating the Network tab:

 [COMPLETION] Starting completion request (attempt 1, mode=legacy)
 POST .../completion  net::ERR_CONNECTION_RESET  200 (OK)
 [COMPLETION] Request failed TypeError: network error
 [COMPLETION] Not retryable error, throwing
 [COMPLETION] Non-API stream error TypeError: network error
 Uncaught (in promise) TypeError: network error
 [COMPLETION] Failed all attempts to invalidate conversation tree with consistency=eventual
 [COMPLETION] message_store_sync_blocked {prev_tree_count: 2, new_tree_count: 0, tree_lost_count: 2}

The 200 (OK) on the same line as net::ERR_CONNECTION_RESET is the key detail. The server accepted the request and began streaming. The Electron renderer then reset its own connection before reading a single byte.

---

Cross-correlation with application logs

From ~/Library/Logs/Claude/claude.ai-web.log, the same session produced 37 instances of this error cluster today. Two of those escalated to:

 [COMPLETION] message_store_sync_loss_accepted

Each message_store_sync_loss_accepted event wiped the entire conversation from Claude Desktop with no recovery option. All API tokens consumed during those sessions were billed but the output is permanently lost.

Cross-referencing mcp-server-cortex.log (which timestamps in UTC) against claude.ai-web.log confirms that every TypeError: network error fires at the exact millisecond a tool result is returned from the MCP server. Zero errors occur during idle periods or during tool execution. The corruption is triggered by result delivery.

---

What is ruled out by this evidence

• Server error: all requests return HTTP 200

• MCP server fault: mcp-server-cortex.log shows all tool calls completing successfully; mcp.log shows no disconnects

• Payload size: failing commands are echo hello, echo world, echo done

• Network instability: the 4th retry succeeded immediately on the same connection

• the 4th retry succeeded on the same connection with no changes

  Hypothesis A recent Claude Desktop release added CLAUDE_STREAM_IDLE_TIMEOUT_MS (visible in the Claude Code changelog) to configure a streaming idle watchdog defaulting to 90 seconds. It is possible the same watchdog is active in Claude Desktop's streaming layer and is being incorrectly triggered by the act of flushing a tool_result chunk rather than by genuine idleness. The result delivery timing correlation in the logs supports this: the reset fires not during idle periods but at the exact moment a tool result arrives. This points to a flush, chunk framing, or connection state management regression introduced in v1.569.0.

  HAR file The full HAR file has been submitted privately via Anthropic support ticket and is available to the engineering team on request. It was not attached here to avoid exposing org ID and conversation content publicly.

  Marking this issue as distinct from the three flagged duplicates. The HAR evidence above was not available in any of the referenced issues and directly identifies the failure layer as the Claude Desktop renderer stream consumer, not the MCP server, not the stdio transport, and not the Anthropic API.