[Windows Desktop 26.818.5229.0] Reopening a task can restore an older conversational checkpoint

What version of the Codex App are you using?

26.818.5229.0 from the Microsoft Store package OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0.

What subscription do you have?

Paid ChatGPT subscription. The exact tier is not visible in the affected task view.

What platform is your computer?

Microsoft Windows 11 Pro 10.0.26200 x64.

What issue are you seeing?

After Codex Desktop restores a task following either a normal app close/reopen or Windows hibernation/resume, a long-running task can continue from an older conversational checkpoint even though newer external actions and local artifacts still exist.

This has happened three times across more than one Codex task. The latest occurrence was on 24 August 2026 in Africa/Lagos.

In the latest case, the task had completed a real external action and received a provider confirmation. The PC was then hibernated. After resume, Codex behaved as if the conversation had returned to a point before that action. The same stale-checkpoint behavior has also occurred after closing Codex normally and opening it again, without hibernating Windows. The external action had not been rolled back, so the agent's restored state disagreed with the real world. After the user corrected Codex and described the missing checkpoint, the task could continue from the newer state.

The failure is easy to miss because the task still opens and the agent responds normally. It does not display a warning that its restored context may be older than completed tool actions. This can cause duplicate email, deployment, billing, DNS, migration, or repository operations.

This report omits the task ID, recipient, message ID, project name, absolute paths, and conversation content. I can provide sanitized metadata privately if a maintainer requests it.

What steps can reproduce the bug?

The problem is intermittent, but the observed sequence is:

1. Open a long-running local project task in Codex Desktop on Windows.
2. Use the task for many turns and tool calls.
3. Complete an external or durable action and receive a success confirmation.
4. Leave the task available in Codex.
5. Either close Codex normally and reopen it, or hibernate Windows and resume the PC.
6. Resume the PC and return to the same Codex task.
7. Send a new prompt that depends on the latest completed action.
8. Codex responds from an older point in the workflow or repeats work that was already finished.
9. Check the external provider or local artifact. The newer action still exists, proving that the world is newer than the restored conversational checkpoint.
10. Correct Codex by restating the missing checkpoint. The task may then recover enough context to continue.

Observed frequency: three occurrences across this task and other chats. The latest followed Windows hibernation. Other occurrences followed a normal Codex close and reopen. Hibernation is therefore not required. The common point is task restoration after the app process or Windows session has stopped.

What is the expected behavior?

After a normal app restart or Windows hibernation, Codex should restore the latest durable conversation and tool state.

If it cannot prove that the restored conversation matches completed side effects, it should warn the user and agent before allowing more external writes or repository changes. The warning should identify the recovery gap and prompt a read-only reconciliation.

Codex should not silently continue from an older checkpoint while newer email, deployment, database, filesystem, or version-control actions remain in place.

Additional information

This is not a report about a missing sidebar entry. The task remains visible and usable. The problem is that the active conversation state can be older than work that already happened.

The recurrence makes the bug hard to dismiss as a one-off model mistake. It has happened three times across separate tasks and makes multi-day production work unsafe because the user cannot tell whether Codex remembers the latest completed action.

Potentially related reports:

• #31982 describes a stale conversational checkpoint after a hard shutdown while durable version-control state is newer.
• #38792 tracks stale Desktop and CLI history projections that do not rebuild from intact rollouts.
• #35935 tracks post-compaction task regression and repeated completed work.
• #32863 tracks older conversation state resurfacing in long-running Windows Desktop workflows.

I am not claiming that those reports share the same root cause. This report adds a current Windows build, both normal app restart and hibernate/resume triggers, three recurrences across tasks, and a durable external side effect that remained newer than the restored conversation.