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

Empieza siguiendo transportError, consumeStream, callModelWithRetry y la ruta de submit mostrada en dist/cli.mjs. Reproduce la interrupción a mitad del stream e inspecciona cómo un body de stream vacío o no parseable se convierte en un error. Se considera terminado cuando la CLI describe el stream interrumpido sin inventar un HTTP 500, preservando al mismo tiempo cualquier estado devuelto realmente.

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.