Interrupted commentary-heavy streams can loop visible retries without substantive progress
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:
- Start a turn that produces a commentary-heavy or long-running stream.
- Interrupt the stream partway through, or hit a transient disconnect before a real completed response arrives.
- Let Codex retry.
- Observe that later attempts may still emit visible commentary or retry narration.
- 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.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
The "visible retries without substantive progress" pattern is a structural problem in agent architectures, not just a UI issue. It happens when the agent's internal retry logic is decoupled from its progress tracking.
We see this manifest in CI pipelines too: an AI agent retries a code generation step, each retry produces slightly different (but equally wrong) output, and the pipeline keeps going because each attempt returns a "success" status. The agent is making progress in its own accounting, but not in any objective sense.
The key insight from your analysis: the retry loop needs an external progress metric, not just the agent's self-assessment. Specifically:
We apply a similar principle in code review: instead of letting the generating agent verify its own output, we run independent checks that compare the result against objective criteria (registry existence for imports, schema validity for API calls, complexity norms for the codebase). This prevents the "confident but wrong" loop.
For anyone dealing with agent retry loops: npx @opencodereview/cli scan . --sla L1 runs deterministic checks that don't rely on the agent's self-assessment of progress.