[BUG] Claude Desktop 1.569.0 — HTTP 200 completion requests deliver 0 bytes (ERR_CONNECTION_RESET), renderer stream consumer torn down before first SSE event

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?

Claude Desktop 1.569.0 on macOS arm64 resets its own streaming
connection after receiving HTTP 200 from the completion endpoint,
before reading a single byte of SSE response data. This happens on
every session that involves a stdio MCP tool call and has been
occurring consistently for approximately two weeks.

The failure was confirmed by HAR capture from DevTools. Four POST
requests to the completion endpoint were recorded during a single
failing session:

Attempt 1: POST /completion → 200 OK, 0 bytes, 2,950ms
Attempt 2: POST /completion → 200 OK, 0 bytes, 5,937ms
Attempt 3: POST /retry_completion → 200 OK, 0 bytes, 16,711ms
Attempt 4: POST /retry_completion → 200 OK, 14,091 bytes (succeeded)

Attempts 1, 2, and 3 received HTTP 200 from the server and then
delivered zero bytes before net::ERR_CONNECTION_RESET fired in the
renderer. The server was healthy and accepting every request. The
connection is being reset inside the Claude Desktop renderer process
immediately after the 200 header lands, before any SSE event is read.

Timestamp cross-correlation between mcp-server-cortex.log (UTC) and
claude.ai-web.log confirms the reset fires at the exact millisecond
a tool result is returned from the MCP server. Zero resets occur
during idle periods or during tool execution itself.

When the reset occurs 4 to 6 times in a session, it escalates to
message_store_sync_loss_accepted, permanently destroying the entire
conversation with no recovery option. All API tokens consumed during
that session are billed but the output is unrecoverable.

This regression has been active for approximately two weeks. During
this period every multi-step development session has been interrupted,
resulting in substantial wasted API spend and completely stalled
project workflows across multiple active codebases.

What Should Happen?

Claude Desktop should maintain a stable SSE streaming connection to
api.anthropic.com throughout the full lifecycle of a conversation,
including before, during, and after any number of MCP tool call
round-trips.

Specifically:

1. A POST to /completion that returns HTTP 200 should stream all SSE

events through to message_stop without resetting the connection.

1. Tool result delivery from a stdio MCP server should have no effect

on the stability of the streaming connection to api.anthropic.com.

1. Conversation history should be fully preserved regardless of how

many MCP tools are invoked in a session.

1. If a transient stream error occurs, the retry logic should recover

without destroying conversation state (no message_store_sync_loss_accepted).

Error Messages/Logs

From DevTools Console, this cluster repeats on every failing tool call:

  [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}

Escalation events from ~/Library/Logs/Claude/claude.ai-web.log
(two occurrences on 2026-04-04 alone):

  2026-04-04 17:50:48 [warn] [COMPLETION] message_store_sync_loss_accepted
  2026-04-04 18:11:33 [warn] [COMPLETION] message_store_sync_loss_accepted

Total recorded on 2026-04-04: 37 network errors, 2 conversation wipes.

From main.log at startup (repeats for every configured stdio MCP server):

  [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

Note: main.log is completely silent about the streaming failure itself.
The crash is never logged there, only in claude.ai-web.log.

Steps to Reproduce

1. Install Claude Desktop 1.569.0 on macOS arm64.

1. Configure a stdio MCP server in claude_desktop_config.json. Any

server with a tool that executes shell commands reproduces this.
Example minimal entry:

{
"mcpServers": {
"my-server": {
"command": "/path/to/node",
"args": ["/path/to/mcp-server/dist/index.js"]
}
}
}

1. Enable DevTools by creating or editing:

~/Library/Application Support/Claude/developer_settings.json
with content: { "allowDevTools": true }

1. Restart Claude Desktop fully (Command + Q, then reopen).

1. Open DevTools with Command + Option + I. Go to the Network tab.

Check "Preserve log". Clear existing entries.

1. Start a new conversation. Ask Claude to invoke the MCP tool 3 or

more times sequentially in a single message. For example:
"Run echo hello, then run echo world, then run echo done"

1. Observe the Network tab: POST /completion requests appear with

HTTP 200 status and 0 bytes in the response body, followed by
net::ERR_CONNECTION_RESET in the Console.

1. Export a HAR file from the Network tab (download icon) to confirm

the 0-byte response pattern across all failed attempts.

1. Check ~/Library/Logs/Claude/claude.ai-web.log for

message_store_sync_blocked and message_store_sync_loss_accepted
entries confirming conversation data loss.

No specific project or repository is required. Any stdio MCP server
with a shell command 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

This bug is in Claude Desktop, not the Claude Code CLI. Filing here as there is no separate public Claude Desktop issue tracker. Claude Desktop version: 1.569.0

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

BUSINESS AND FINANCIAL IMPACT

This regression has been active for approximately two weeks. My
entire development workflow runs through Claude Desktop with a custom
stdio MCP server (Cortex) that executes terminal commands across
multiple active projects. Since this regression appeared, I have been
unable to complete a single multi-step development session without
losing the conversation and all work performed in it.

Every destroyed conversation (message_store_sync_loss_accepted)
represents API tokens that were consumed and billed but whose output
is permanently lost. On 2026-04-04 alone, 274 MCP tool calls were
logged. Over two weeks, the cumulative wasted spend on a Team
subscription is substantial. More critically, all four of my active
development projects are currently stagnant because the core
automation workflow is broken.

DEVTOOLS AND HAR EVIDENCE

Following guidance from Anthropic support, DevTools was enabled and
a full HAR was captured during a reproducible session. The HAR
confirms HTTP 200 with 0-byte response bodies on failing requests
(see What's Wrong section above). The HAR file has been submitted
privately via Anthropic support ticket to avoid exposing org ID and
conversation content. It is available to the engineering team on
request.

HYPOTHESIS

The CLAUDE_STREAM_IDLE_TIMEOUT_MS watchdog added in a recent Claude
Code release (defaulting to 90s, visible in the public changelog)
may also be present in Claude Desktop's streaming layer. It may be
incorrectly triggered by flushing a tool_result chunk rather than
by genuine idleness. The reset fires consistently at result delivery,
not during execution, pointing to a flush or connection state
management regression in v1.569.0.

WHY THIS IS NOT A DUPLICATE

This report leads with HAR evidence of HTTP 200 returning 0 bytes,
which is not present in any previously filed issue. Specifically:

• #33969: graceful pause_turn banner with a Continue button. This

bug produces a silent 0-byte stream reset with no UI recovery.

• #22299: Windows only, tool calls never reach the MCP server. In

this bug all tool calls reach the server and complete successfully.

• #37806: invocations never reach the server. Opposite of this bug.
• #31752: HTTP 409 during SSE reconnection. No 409 appears anywhere

in this trace.

• #38437: proxy hang. This fires immediately at result delivery,

not after a stall.

RELATED ISSUES FILED BY SAME REPORTER

#43642 and #43676 were filed earlier today and both incorrectly
closed as duplicates before this HAR evidence was available.

LOG FILES

Three log files (claude.ai-web.log, mcp-server-cortex.log, main.log)
were attached to issue #43676 and are available for cross-reference.