In conversations with dozens of turns, codex starts to reply to a message but 'forgets' it after the first split
What version of Codex CLI is running?
codex-cli 0.120.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.4
What platform is your computer?
Linux 6.17.0-14-generic x86_64 x86_64
What terminal emulator and version are you using (if applicable)?
Gnome Terminal
What issue are you seeing?
In long conversations (this bug always appears when a conversation is sufficiently long in terms of the number of turns, definitely more than 10), sometimes codex starts replying (analyzing, implementing, etc.) in reply to the latest prompt, but after the first "split" (horizontal line, I don't know the proper term for it in codex parlance) it 'forgets' about my latest message and its first-split work and clearly continues to reply to my previous (penultimate) message.
What steps can reproduce the bug?
Seems to be reproducible quite consistently. At least half of long (dozens of turns) conversations. (Maybe even all of them, but I didn't keep the exact tally.)
What is the expected behavior?
_No response_
Additional information
This issue has been present for a while, over many versions of codex. I think at least since gpt-5.3-codex (early Feb). I didn't report it because I thought this is an 'obvious' bug that should be reported by someone else, but found it surprising it's still not fixed.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
This context-forgetting pattern in long conversations is a significant reliability issue for anyone using Codex for extended development sessions. The model starts a response, hits a context window split, and then loses track of what it was doing.
What makes this particularly insidious: the partial response before the split often looks complete and intentional. The model might have written 3 out of 5 functions in a refactoring task, and the response ends at a natural-looking boundary. The user might not realize the work is incomplete until they try to run the code.
We have observed a related pattern in multi-session AI coding: an agent starts implementing a feature, gets interrupted (context compaction, session break, or in this case a turn split), and then resumes with a slightly different understanding of the requirements. The result is code that works in isolation but contradicts the partial implementation from the first session — same variable names, different semantics.
The traditional quality gates do not catch this because each piece of code is individually correct. The bug is in the semantic gap between the two halves — something that only emerges when you analyze the complete diff as a coherent unit rather than as independent changes.
One practical mitigation: adding a coherence check that compares the implementation plan (usually stated at the beginning of a response) against what was actually implemented. If the plan says "5 functions" and only 3 exist, flag it. This catches the context-loss pattern without needing to understand the code itself.
npx @opencodereview/cli scan . --sla L1