Codex sometimes has "stale task-state hallucinations"

What version of the IDE extension are you using?

26.506.31421

What subscription do you have?

plus

Which IDE are you using?

VS Code

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

Codex sometimes appears to lose track of the latest task state and continues from an older state of the conversation. I have seen this more than once. The most recent example involved git status, but the issue is not necessarily git-specific.

In the most recent case, I asked it to commit the current refactor slice and proceed. It correctly committed the pending files. It then only ran read-only inspection commands for the next possible slice. However, its final response claimed it had "proceeded with the next slice" and listed files as "currently uncommitted" even though those files were the ones it had just committed and git status --short was clean.

From my side this looked like Codex asserting that it had edited files when it had not touched anything after the commit. When challenged, Codex reviewed the rollout and confirmed that the final response was stale/incorrect.

A previous instance of the same class of issue was worse and had no direct relation to git. I sent a message, Codex did the work/review and reported results. I then sent a follow-up message, and Codex behaved as if the two latest messages did not exist: it started reasoning from my pre-previous message, then usually reported the same result it had already reported one message earlier, just in different words.

Screenshots:

Codex claims there are current uncommitted files after commit c300422.
<img width="700" alt="Image" src="https://github.com/user-attachments/assets/93545c11-1ee0-4edd-a9cc-d4958f4092ec" />

Codex later identifies the failure as "stale task-state hallucination".
<img width="700" alt="Image" src="https://github.com/user-attachments/assets/f28227ba-7e07-4b1d-8a6a-34bd62263f0a" />

What steps can reproduce the bug?

I do not have a minimal deterministic repro. The general pattern is that in a longer session, after completing and reporting a task, Codex sometimes answers the next user message using stale task state instead of the latest conversation state.

Recent concrete sequence:

1. Work through several repeated cycles of: implement refactor slice, verify, commit, proceed.
2. Have an existing uncommitted slice.
3. Ask: Then pls commit and proceed.
4. Codex runs git status --short, commits the pending files, then runs only read-only inspection commands for the next area.
5. Codex final response says it proceeded with a next slice and lists "current uncommitted files" that are already committed.

Earlier observed sequence:

1. User sends task/review request.
2. Codex does the work and reports results.
3. User sends a follow-up.
4. Codex behaves as if the work/report and follow-up did not happen, resumes from the pre-previous request, and repeats the previous result in different words.

Rollout evidence from the affected session:

• User request was at rollout line 9321.
• git status --short before commit showed:
• M src/codex_sessions_converter/converter.py
• M src/codex_sessions_converter/markdown_tools.py
• ?? src/codex_sessions_converter/session_search.py
• ?? tests/test_session_search.py
• Codex committed them as c300422 Extract session search workflow.
• The next git status --short output was empty.
• Codex only read transfer.py, converter.py, and searched for import/export functions.
• Final response nevertheless claimed the same files were "currently uncommitted".

What is the expected behavior?

Codex should always ground its next response in the latest user message and latest tool/state observations, not in a stale internal task narrative.

For the git example, after a commit, Codex should base its final status on the latest actual repository state. If git status --short is clean and it only ran read-only inspection commands, it should say something like:

Committed c300422. I inspected the import/export area for the next slice but did not make new edits.

It should not claim to have proceeded with edits or list committed files as uncommitted. More generally, after a follow-up message, it should not resume reasoning from an older user request or repeat the previous result as if the latest turn did not happen.

Additional information

This happened in a long-running VS Code Codex session after many similar "commit previous slice, proceed next" iterations. The recent git example looks like stale task-state bookkeeping: the assistant reused the pre-commit file list in its final response instead of grounding the response in the latest tool output.

The broader concern is that the same stale-state behavior can happen across normal user turns too, where Codex appears to ignore the latest assistant result and user follow-up and continues from an older task state.

No Steering was used during the affected turn. I did not interrupt or otherwise interfere with the running task, nor with the previous task before it finished. There were no concurrent tasks running in other sessions at the time. Also, no context compaction appeared during the whole described sequence of involved messages.

---

The relevant rollout slice:

rollout-stale-task-state-slice.jsonl.txt

Search for "Then pls commit and proceed".

Tell me if you need anything else to help debug this, as this is a serious correctness problem.