codex - 💡(How to fix) Fix Interrupted commentary-heavy streams can loop visible retries without substantive progress [2 comments, 3 participants]

What version of Codex is running?

Observed in current Responses/WebSocket-era builds; the exact version is less important than the retry behavior in the core turn loop.

What subscription do you have?

No response

Which model were you using?

No response

What platform is your computer?

Platform-independent.

What terminal emulator and version are you using (if applicable)?

No response

What issue are you seeing?

Interrupted streams can produce visible commentary or retry narration, but still fail to make substantive progress toward a completed turn.

The problem is that visible output appears to count as progress strongly enough that the retry loop can keep going even when the user is not getting a real completion.

From the outside, the session looks active because you may still see commentary, reconnect text, or partial reasoning narration. But the turn is not actually converging on a completed response, and the retry loop is not classifying that lack of substantive progress honestly.

What steps can reproduce the bug?

A generic reproduction shape is:

1. Start a turn that produces a commentary-heavy or long-running stream.
2. Interrupt the stream partway through, or hit a transient disconnect before a real completed response arrives.
3. Let Codex retry.
4. Observe that later attempts may still emit visible commentary or retry narration.
5. Despite that visible output, no real completed answer arrives, and the turn can remain in a misleading retry loop.

What is the expected behavior?

Visible-only commentary should not indefinitely reset the no-progress logic.

If repeated attempts keep producing visible narration but no substantive completion, Codex should:

• preserve enough visible context for the user to understand what happened
• avoid treating commentary-only retries as meaningful forward progress
• terminate or classify the failure honestly after bounded retries

Additional information

This looks separate from pure websocket reconnect detection.

Related issues such as #17199, #17003, and #17201 describe reconnect loops or dead-connection symptoms. This report is narrower: the bug is in how the retry loop classifies progress once visible output exists but completion still never arrives.

A local fork validated a narrow runtime slice for this behavior using:

• cargo test -p codex-core stream_no_completed -- --nocapture

The affected core area is the turn/retry loop in codex-rs/core/src/codex.rs, plus retry outcome classification in protocol/runtime error handling.