Session lost after battery shutdown + update — no rollout persisted for resumable session
What version of the Codex App are you using (From “About Codex” dialog)?
codex-cli 0.122.0
What subscription do you have?
ChatGPT Plus (monthly subscription)
What platform is your computer?
Linux Mint 21.3 (kernel 5.15.0-174-generic, x86_64)
What issue are you seeing?
A long-running Codex CLI session was lost and cannot be resumed after a normal system shutdown (battery depletion) followed by a Codex update.
The session had already reached the usage/query limit and stopped accepting input, so it should have been in a stable terminal state.
After restarting the system and updating Codex (as prompted), the session is no longer available via codex resume.
No session rollout exists for that day under ~/.codex/sessions.
What steps can reproduce the bug?
- Start a long Codex CLI session
- Work until the usage/query limit is reached
- Leave the machine running on battery
- System performs normal shutdown due to low battery
- Restart the machine
- Launch Codex and attempt to resume session
- Codex prompts for update → perform update
- Attempt to resume again
What is the expected behavior?
A session that has reached a terminal state (such as usage/query limit) should be persisted to disk and recoverable via codex resume after restart.
Additional information
Diagnostics:
- ~/.codex/sessions contains only:
- 2026/04/14
- 2026/04/19
- No directory exists for 2026/04/22
- ~/.codex/history.jsonl was updated on 2026-04-22 (activity confirmed)
- ~/.codex/state_5.sqlite exists but is reused from previous sessions
- No rollout .jsonl file exists for the lost session
System shutdown was clean (battery threshold triggered OS shutdown).
In previous similar situations, codex resume worked correctly after restart.
This suggests that the session was never flushed to disk in a resumable form.
Impact:
Several hours of work lost with no recovery path.
This behavior makes Codex unreliable for long-running sessions unless external logging is used.
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Regarding the potential duplicate suggested above (#18690):
This does not appear to be the same issue.
The linked issue describes rollout files not being written until the first API turn completes (i.e. very early in the session lifecycle).
In my case:
Given that rollout files are written after the first API turn, a rollout file should already have existed long before shutdown.
The absence of any rollout file suggests a failure in persistence after an established session, not a delay in initial rollout creation.
This appears to be a different and more severe failure mode, as it results in complete loss of a progressed session.
Not sure if this is directly related, but this issue was automatically linked to #19081 (macOS app crash on long tasks).
In my case:
However both cases seem to involve long-running sessions and possible state persistence problems.
A resumable session should have an append-only checkpoint before it reaches any long-lived terminal state.
When usage limit is hit, write and flush a stable record with session id, cwd, model, last completed turn id, limit/error state, and source file path. Then shutdown/update recovery can list the session even if no later assistant turn is accepted.
The missing rollout is the hard part to diagnose after the fact.
---
_Generated with ax._
When sessions appear lost after unexpected shutdowns or updates, they are sometimes misfiled under other date partitions or unindexed in
state_5.sqlite.Codex Rescue scans the local filesystem directly to locate unindexed, misplaced, or orphaned rollouts:
Or run doctor across all discoverable sessions:
It operates strictly read-only and local-first. If you run it, the session list can verify whether any misplaced rollout file survived.