Codex resumes from a stale conversational checkpoint after hard shutdown while VCS state is newer
What version of Codex CLI is running?
26.707.31428
What subscription do you have?
Enterprise
Which model were you using?
gpt-5.6-sol
What platform is your computer?
Darwin 25.3.0 arm64 arm
What terminal emulator and version are you using (if applicable)?
iTerm2
Codex doctor report
What issue are you seeing?
After the computer froze completely and required a hard shutdown, the Codex App resumed a long-running coding task from a stale conversational checkpoint.
The restored conversation was 2 hours and 20 seconds behind the durable version-control state:
- Last persisted session entry:
2026-07-09 18:27:18.985 EDT - Last durable VCS operation absent from the restored session:
2026-07-09 20:27:38.904 EDT - Difference:
2h 00m 19.919s
A separate commit timestamp corroborates the gap:
- Latest commit absent from the restored session:
2026-07-09 20:16:46.000 EDT - Difference from the session checkpoint:
1h 49m 27.015s
The filesystem, commits, rebases, bookmark movements, and other VCS operations from the missing period remained present locally. However, the resumed agent had no memory of performing them and began repeating the work.
The discrepancy was discovered only after inspecting the VCS operation log. Until then, the task appeared to have resumed normally.
This is particularly dangerous because it is not obvious session loss. The agent continues confidently from stale beliefs about the workspace, creating a risk of duplicate commits, conflicting rebases, or overwriting valid completed work.
What steps can reproduce the bug?
This was the observed sequence:
- Start a long-running local coding task in the Codex App.
- Let the agent edit files, run tests, create commits, and perform version-control operations over an extended period.
- Have the computer freeze while the task is active.
- Perform a hard shutdown.
- Restart the computer and resume the same Codex App task.
- Observe that the agent continues from an older conversational checkpoint.
- Ask the agent to continue working.
- The agent starts repeating work because it does not know that later operations already occurred.
- Compare the persisted session timestamps with the filesystem and VCS operation log.
- Observe that durable workspace operations continue for approximately two hours beyond the last restored session entry.
What is the expected behavior?
After an ungraceful shutdown, Codex should restore the latest durable conversation and tool state that is consistent with the workspace.
If the conversation cannot be recovered to a checkpoint consistent with durable tool side effects, Codex should detect the recovery gap and clearly warn both the user and agent before allowing further mutations.
Codex should not silently resume from an older conversational checkpoint while newer filesystem or version-control side effects remain in the workspace.
At minimum, recovery should do one of the following:
- Restore the latest durable conversation and tool history.
- Roll back workspace effects to the recovered checkpoint, if that can be done safely and explicitly.
- Detect that the workspace is newer than the conversation and halt with a recovery warning.
- Provide a reconciliation view showing unrepresented tool or filesystem operations.
Additional information
This differs from complete session loss: the task remained resumable and newer workspace changes survived, but the restored agent context was stale.
That mismatch is more hazardous than an obviously missing session because the agent can unknowingly duplicate or overwrite valid work.
The workspace used Jujutsu backed by Git. Its operation log provided precise timestamps for durable mutations, making it possible to measure the stale-state gap.
Related reports:
- #19037
- #16300
This may share a persistence or rollout-flush root cause with those reports, but this report focuses on a partially recovered session whose conversational state is approximately two hours older than its durable workspace state.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗