Codex sometimes returns a stale final answer from an earlier turn instead of answering the latest message
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.406.31014 (1395)
What subscription do you have?
Business / Pro-style desktop usage
What platform is your computer?
macOS
What issue are you seeing?
In a long-running Codex Desktop conversation, Codex sometimes starts a new turn correctly, acknowledges the latest user request in commentary/planning, but then emits a final answer copied from an earlier completed turn instead of answering the current request.
Resending the same prompt in the next turn often makes Codex behave normally.
This does not look like a UI-only display issue because the wrong final answer is already present in persisted session history for the affected top-level vscode thread.
I have now seen multiple variants of this in the same conversation:
- A task about update-host configuration was replayed when I asked for a swipe-back UI change.
- The same update-host completion was replayed later when I agreed to proceed with websocket reconnect work.
- A swipe-back completion was replayed later when I asked for websocket auto-reconnect and disconnect-status UX.
The strongest signal is that the bad turns often have only read/view tool activity, or very few tool events, yet the final answer claims code changes, tests, and release/publish steps that belong to an earlier completed turn.
That strongly suggests an old completed final answer is being attached to the wrong new turn.
What steps can reproduce the bug?
I do not have a short deterministic repro yet, but the observed pattern in one long-running desktop thread is:
- Ask Codex to do task A.
- The first response may incorrectly reuse a previous completed task's final answer.
- Resend task A.
- Codex then performs task A correctly.
- Ask Codex to do task B.
- Codex commentary/planning clearly starts task B.
- The final answer is not about task B. It replays a completion from task A or another older task.
- Resend task B.
- Codex then performs task B correctly.
Concrete examples I observed:
- Update-host config task
- Swipe-back/navigation task
- Websocket reconnect/disconnect-status task
In the reconnect example, Codex commentary started the correct reconnect/disconnect-status implementation lane, but the final answer replayed an older swipe-back completion instead.
What is the expected behavior?
Codex should always finalize the current turn using the current turn's request and state.
If the assistant starts the correct new task in commentary/planning, the final answer should not resolve using stale output from an earlier completed turn.
Additional information
This looks more like session/turn-final orchestration than simple model drift because:
- the bad turn already contains the wrong final answer in persisted session history
- the wrong final can reference old completed work products even when the current turn only performed read-only inspection
- repeating the same user request in the next turn often succeeds immediately
- different stale finals can be replayed, suggesting this is not limited to the immediately previous turn
Possibly related issues:
- CXA-2590 Codex suddenly outputs an identical response from a previous turn after completing several instructions
- CLI-4236 Codex stops execution mid turn and answer an old unrelated question
- CLI-3843 gpt-5.4 generates response to earlier messages not the last user message
- CLI-2702 Codex replies to earlier messages instead of latest one in conversations
- [#11174](<https://github.com/openai/codex/issues/11174>) When context is auto compacted, agent forgot question already answered in previous turn
I also have local redacted session-history evidence showing:
- the bad turn started normally
- the current prompt was recorded correctly
- commentary referenced the current prompt correctly
- the final answer matched a stale earlier completion instead
If useful, I can provide a private redacted evidence bundle with exact turn boundaries and examples.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗