›_ Codex Issues
Codex Issues / #15318

Codex suddenly outputs an identical response from a previous turn after completing several instructions

Open 💬 5 comments Opened Mar 20, 2026 by DeerYang
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.313.41514

What subscription do you have?

Business

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

I'm encountering a frustrating and recurring bug in very long-running Codex sessions: after processing several instructions successfully, Codex suddenly outputs a response that is identical to one of its earlier replies from several turns ago. This has happened to me three times so far in a single ultra-long conversation thread where I've accumulated several million tokens of total usage.

What steps can reproduce the bug?

  1. The session starts normally and runs smoothly for dozens of turns, session ID: 019c7b56-df49-7141-b172-04d41af15c0a.
  2. Codex handles each task correctly, often involving tool calls, file edits, or long outputs. 
  3. After 20–50+ successful turns (and very high cumulative token count), when I send a brand-new prompt
  4. Codex begins the turn normally, often with its planning prefix, executes a series of simple viewing/reading-type instructions. and suddenly outputs a response that is identical to one of its earlier replies.

What is the expected behavior?

_No response_

Additional information

Right after the duplicate occurred, I asked: "Why did you just output an identical response to one from much earlier in our conversation?"
Codex did not recognize or admit any repetition/bug. Instead, it replied along the lines of:
"The tasks involve similar operations (reviewing or presenting academic content), so I applied a consistent expression template for clarity and coherence."
This explanation is incorrect — the output was not a "similar template"; it was a complete, verbatim copy of a prior full response.
I use 5.4 high and this seems tied to extremely long contexts (millions of tokens accumulated over hours/days of continuous work). It never happened in shorter sessions.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 5 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #14805

Powered by Codex Action

DMIGitH · 5 months ago

I’ve been screaming at codex the past several days as it is working on an issue and suddenly it wants to fix a previous issue that was already resolved.
The context % is nothing to do with the issue. I’m getting rid of 5.4 hoping this and other problems go away. 5.4 likes to assume it knows best and it keeps injecting unwanted concepts.

137alpha · 5 months ago

I've uploaded a conversation with this. See thread ID 019d240e-99a6-76e1-8b35-8e349ffc468

liqiang311 · 5 months ago

I run into this a lot too. It’s driving me crazy.
GPT 5.4

LEON-gittech · 4 months ago

I think I've found a TUI-level root cause that contributes to this symptom, and we have a local fix.

The Race Condition

In the TUI layer (chatwidget.rs), when a user sends a new prompt while the previous turn still has in-flight delta frames (or when network latency causes reordering), stale delta events from the previous turn can arrive after the new turn has already started. Without guards, these stale events are processed as if they belong to the current turn.

This means:

  • AgentMessageDelta from turn N-1 gets appended to the active cell of turn N
  • TurnComplete from turn N-1 can incorrectly end the current turn
  • PlanDelta / ReasoningDelta from an old turn pollutes the current turn's output

Our Fix

We added a turn_id field to all streaming delta events and guard every live-event handler in the TUI with a should_accept_live_turn_output(turn_id) check:

Events now carry turn_id:

  • AgentMessageDelta
  • AgentReasoningDelta
  • AgentReasoningRawContentDelta
  • AgentReasoningSectionBreak
  • PlanDelta
  • TurnComplete
  • ItemCompleted

Guard logic in chatwidget.rs:

fn should_accept_live_turn_output(&self, turn_id: &str) -> bool {
    self.last_turn_id
        .as_deref()
        .is_none_or(|current_turn_id| current_turn_id == turn_id)
}

Any event whose turn_id does not match last_turn_id is dropped with a debug log:

"dropping stale agent message delta for non-current turn"

Why This Matters for #15318

In ultra-long sessions with high token counts, the combination of:

  1. Large context windows → slower turn transitions
  2. High delta volume → more chances for in-flight frames to cross turn boundaries
  3. Compaction or reconnects → event reordering

...creates the exact conditions where stale deltas from an earlier turn leak into a later one, producing the "identical response from a previous turn" symptom described here.

Our fix is purely in the TUI layer and is backward compatible (events without turn_id still work via fallback). Happy to share the patch or open a PR if the team is interested.