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，同时保留实际返回的任何状态。