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

Comece rastreando transportError, consumeStream, callModelWithRetry e o caminho de submit mostrado em dist/cli.mjs. Reproduza a interrupção no meio do stream e inspecione como um body de stream vazio ou não analisável se torna um erro. Está concluído quando a CLI descreve o stream interrompido sem inventar um HTTP 500, preservando qualquer status realmente retornado.

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.