[BUG] API Error: Connection closed mid-response (ECONNRESET on every streaming request) with third-party Anthropic-compatible endpoint — works on 2.1.220, broken on 2.1.224

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 Code 2.1.224 on Windows fails every streaming API request to a third-party Anthropic-compatible endpoint (DeepSeek's /anthropic endpoint). The stream starts normally (first chunk arrives ~400 ms), then the connection is reset (ECONNRESET) 0.5–5 seconds later. After several automatic retries (1/10 through 8/10) that all fail the same way, the session ends with:

API Error: Connection closed mid-response. The response above may be incomplete.

The same machine, same configuration, same endpoint work perfectly on 2.1.220 (no ECONNRESET at all, full response received).

What Should Happen?

A normal streamed response, exactly as on 2.1.220.

Error Messages/Logs

[DEBUG] [API REQUEST] /anthropic/v1/messages source=sdk
[DEBUG] Stream started - received first chunk
[DEBUG] [API:timing] first byte after 422ms
[WARN] Stream connection error (ECONNRESET) — retrying streaming (1/10)
[WARN] Stream connection error (ECONNRESET) — retrying streaming (2/10)
[WARN] Stream connection error (ECONNRESET) — retrying streaming (3/10)
[WARN] Stream connection error (ECONNRESET) — retrying streaming (4/10)
[WARN] Stream connection error (ECONNRESET) — retrying streaming (5/10)
[WARN] Stream connection error (ECONNRESET) — retrying streaming (6/10)
[WARN] Stream connection error (ECONNRESET) — retrying streaming (7/10)
[WARN] Stream connection error (ECONNRESET) — retrying streaming (8/10)
[WARN] Stream connection closed (ECONNRESET) after 1 block(s) yielded — finalizing partial response
API Error: Connection closed mid-response. The response above may be incomplete.

Steps to Reproduce

1. Point Claude Code at a third-party Anthropic-compatible endpoint via ANTHROPIC_BASE_URL + ANTHROPIC_AUTH_TOKEN.
2. Run: claude -p "hello" --debug-file cc224.log
3. Observe repeated Stream connection error (ECONNRESET) — retrying streaming (n/10) followed by the final API Error: Connection closed mid-response.

Attached logs:

• cc224-redacted.log — failing run on 2.1.224 (repeated ECONNRESET + retries)
• cc220-redacted.log — successful run on 2.1.220 (same command / config / machine, zero ECONNRESET)
• request-redacted.json — the exact request body captured via OTEL raw-body telemetry on 2.1.224
• response-redacted.json — the partial response body captured on 2.1.224

cc220-redacted.log
cc224-redacted.log
request-redacted.json
response-redacted.json

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

Yes, this worked in a previous version (2.1.220)

Claude Code Version

2.1.224 (npm install)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Server side is fine — we replayed the exact captured request body (~64k input tokens, 111 tools, 8 beta flags, output_config.effort=max, messages[1].role="system") directly against the endpoint using Node 22 and Bun 1.3.14 from the same machine/network: HTTP 200 with a complete stream every time.

OTEL raw-body capture shows the request is sent, DeepSeek returns a thinking block, then the telemetry event reports status: "disconnected" and the response has output_tokens: 0. The failure is specific to the bundled runtime (claude.exe, Bun v1.4.0): the identical request succeeds with Bun 1.3.14 and Node on the same machine.

Notable request details (2.1.224):

• betas: claude-code-20250219, context-1m-2025-08-07, interleaved-thinking-2025-05-14, thinking-token-count-2026-05-13, context-management-2025-06-27, prompt-caching-scope-2026-01-05, mid-conversation-system-2026-04-07, effort-2025-11-24
• output_config: {"effort":"max"}
• messages[1].role is "system" (the Messages API normally only allows user/assistant roles inside messages)
• 111 tool definitions (~205 KB), including 82 MCP tools
• max_tokens: 32000, stream: true

Additional context: 2.1.223 was auto-rolled-back on this machine by the built-in blocked-version list, and 2.1.224 still exhibits this streaming issue on third-party endpoints. This looks like a regression in the bundled Bun 1.4.0 networking stack / SDK streaming path when talking to non-Anthropic upstreams, not a server-side problem.