CLI reports a fabricated HTTP 500 when the response stream drops mid-flight

Summary

When a response stream drops mid-flight, the CLI surfaces submit_error: Error: 500 ERROR even though nothing in the request path ever returned a 500. Tracing a reproduction end to end: POST /alpha/generate returned HTTP 200, the upstream provider fetch returned HTTP 200, content type text/event-stream, first chunk arrived at ~2-3s TTFT — and then the stream terminated with 0 input / 0 output tokens recorded.

The 500 is fabricated by our own error formatter. Users read it as a server outage and open support tickets for an incident that isn't happening.

Expected Behavior

The error should describe what actually happened — the response stream ended before completion — and must not name an HTTP status code that was never returned. If a status is shown it should be the one the API actually sent.

Actual Behavior

After the retry budget is exhausted (7 attempts with backoff), the CLI prints:

submit_error: Error: 500 ERROR

Type "continue" to try again. If the issue persists, contact support: ...

The trailing ERROR is the exception message itself. transportError() builds a TransportError from the stream body, and when that body is empty or unparseable the message degrades to the literal string ERROR. The submit path then prefixes an unrelated 500.

Stack from a captured failure:

TransportError: ERROR
    at transportError (.../dist/cli.mjs)
    at consumeStream (.../dist/cli.mjs)
    at async Object.complete (.../dist/cli.mjs)
    at async callModelWithRetry (.../dist/cli.mjs)
    at async agentLoop (.../dist/cli.mjs)

Steps to reproduce the issue

1. Start a session and drive the conversation until each request payload is several MB (large tool outputs — build logs, installs, file dumps — do this quickly).
2. Send a prompt.
3. The stream opens, delivers a first chunk, then aborts roughly 10s in with no usage recorded.
4. The CLI retries 7 times and then reports submit_error: Error: 500 ERROR.

Any upstream mid-stream abort reproduces the mislabelling; the oversized payload is just a reliable way to trigger one.

Command Code Version

1.32.1

Operating System

Windows

Additional context

Same user-visible symptom as #597, where the reporter also noted token consumption was 0 — consistent with a stream that opens and aborts before emitting usage. The message text varies with what the upstream returns (500 ERROR, 500 Network connection lost), but the invented 500 prefix is common to both.

The oversized-payload trigger has its own root cause: #756.

首先追蹤 dist/cli.mjs 中顯示的 transportError、consumeStream、callModelWithRetry 和 submit 路徑。重現串流在中途被中止的情況，並檢查空的或無法解析的串流 body 如何變成錯誤。完成標準是 CLI 能描述被中斷的串流，而不會憑空捏造 HTTP 500，同時保留實際回傳的任何狀態。