Repository navigation
Codex Desktop loses completed post-recovery conversation after restart and restores stale interrupted checkpoint #43885
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Unknown — I am using the Codex Desktop app and have not yet been able to determine the exact version.
What subscription do you have?
Plus
What platform is your computer?
Windows
What issue are you seeing?
SUBJECT:
Codex Desktop loses completed work/conversation after app restart and restores an old interrupted checkpoint
DESCRIPTION:
I am experiencing a serious persistence/recovery issue in Codex Desktop.
The problem started after an unexpected power outage while Codex was actively working on a task.
At the exact moment of the power outage, Codex had not yet finished the active task.
After power was restored, I reopened ChatGPT/Codex and instructed Codex to continue the interrupted work.
Codex successfully continued from that point.
The important part is:
THE RESUMED WORK WAS COMPLETED SUCCESSFULLY.
I could see the continuation messages, commands, work progress, file changes, verification, and final result normally inside the Codex conversation.
After the work was completely finished, I closed the ChatGPT/Codex application completely.
Later, when I opened the application again, the completed continuation had disappeared.
The conversation had reverted to the OLD CHECKPOINT from the moment when the power outage originally interrupted Codex.
All messages and completed work shown in the conversation after that interrupted checkpoint were no longer visible.
The UI behaved as if the resumed/completed work had never happened.
DETAILED TIMELINE:
-
Codex was actively working on a task.
-
A power outage unexpectedly shut down the computer while the task was still running.
-
After power was restored, I reopened ChatGPT/Codex.
-
The conversation correctly showed the task at the interrupted point.
-
I explicitly instructed Codex to continue the interrupted work.
-
Codex continued working.
-
Codex performed the remaining work and eventually completed the task.
-
The completed continuation was visible normally in the conversation.
-
I then gave Codex another separate instruction for additional work.
-
Codex also performed that additional work successfully.
-
The new messages, commands, changes, verification steps, and final result were visible normally.
-
I completely closed the ChatGPT/Codex application.
-
When I reopened the application, BOTH sets of completed post-recovery work had disappeared from the conversation.
-
The conversation had reverted again to the old checkpoint from the original power outage.
-
The UI currently shows the old interrupted state and a Play/continue button, as though Codex still needs to continue from that old point.
This is incorrect because that interrupted work had already been resumed and completed before the application was closed.
IMPORTANT OBSERVATION:
The issue is NOT simply that an active task was interrupted by the power outage.
I fully understand that an unexpected shutdown can interrupt an active task.
The actual problem is what happens AFTER recovery:
- Codex is reopened.
- The interrupted task is resumed.
- Codex completes the task.
- The completed work is visible normally.
- Additional new work can also be performed and completed.
- Everything appears correct while the application remains open.
- After fully closing and reopening the application, the conversation rolls back to the OLD interrupted checkpoint.
- Completed conversation history after that checkpoint disappears.
This means the application appears capable of continuing the session temporarily, but the recovered/completed session state is not being persisted or reconstructed correctly after a full application restart.
SECOND OCCURRENCE:
This was not a one-time event.
After the first recovered task had been completed, I later gave Codex another new instruction.
Codex performed the new work and completed it.
I again confirmed that the result was visible in the conversation.
I then completely closed the application.
After reopening it, that newer completed work disappeared as well.
Once again, Codex returned to the same old interrupted checkpoint from the original power outage.
Therefore the problem appears persistent for this conversation/session after the original unexpected shutdown.
CURRENT UI STATE:
The conversation currently displays the old messages from around the interrupted task.
It also shows a Play/continue control, which appears to indicate that Codex believes the old interrupted operation still needs to be resumed.
However, that operation had already been resumed and completed.
Work performed after that point is missing from the visible conversation after restarting the application.
EXPECTED BEHAVIOR:
After an interrupted task is resumed and subsequently completed:
-
The recovered continuation should become part of the permanent conversation history.
-
The final completed task state should replace the old interrupted/in-progress state.
-
New messages and work performed afterward should also persist normally.
-
Closing and reopening the application should restore the latest completed conversation state.
-
An old interrupted checkpoint should NOT become active again after the task has already been resumed and completed.
-
The UI should NOT offer to resume an obsolete operation that was already completed.
ACTUAL BEHAVIOR:
After closing and reopening the application:
- completed continuation messages disappear;
- later completed work also disappears;
- the conversation rolls back to the original interrupted checkpoint;
- the old task appears resumable again;
- the Play/continue button is shown for the obsolete interrupted state;
- the latest visible session state is not preserved.
SEVERITY:
HIGH / DATA-PERSISTENCE / SESSION-INTEGRITY ISSUE
This issue is especially serious for long-running Codex work because it creates uncertainty about:
- whether completed work is still recorded;
- whether the latest conversation state is durable;
- whether pressing Continue/Play will accidentally repeat already-completed work;
- whether file changes and conversation state still correspond;
- whether verification/evidence produced after recovery still exists;
- whether subsequent instructions are attached to the correct session state.
RISK:
The largest risk is not merely losing chat messages.
If the filesystem/workspace retains changes from the completed work while the Codex conversation rolls back to an older state, Codex may incorrectly believe that the old operation still needs to run.
Continuing from that stale checkpoint could potentially cause:
- duplicate modifications;
- repeated commands;
- repeated tests;
- conflicting edits;
- duplicated evidence;
- incorrect assumptions about current workspace state;
- accidental regression of already-completed work.
Therefore I do not consider simply pressing the Play/Continue button to be a safe recovery method until the session-state inconsistency is understood.
LIKELY CATEGORY OF ISSUE:
This appears to be related to one or more of the following:
- conversation/session persistence;
- interrupted-turn recovery;
- stale in-progress task state;
- history reconstruction after application restart;
- session checkpoint persistence;
- post-crash/post-power-loss recovery;
- synchronization between durable task history and the Desktop UI.
I am NOT claiming which internal component is responsible.
I am reporting the observable behavior only.
REPRODUCTION SEQUENCE:
A simplified reproduction pattern based on what happened:
- Start a Codex task.
- Unexpectedly terminate the machine/application while Codex is actively working.
- Restart the machine.
- Reopen Codex.
- Resume the interrupted task.
- Allow Codex to finish successfully.
- Confirm that the completed continuation appears in the conversation.
- Optionally submit another new task and allow it to finish.
- Completely close the ChatGPT/Codex application.
- Reopen the application.
- Observe that the conversation has reverted to the old interrupted checkpoint and the completed post-recovery history is missing.
SCREENSHOT EVIDENCE:
I have a screenshot showing the old interrupted checkpoint that reappears after restarting the application.
The screenshot includes:
- previous Codex execution messages;
- "Context automatically compacted";
- multiple "Ran commands" entries;
- an "Edited 8 files" result;
- the usage-limit message visible at the time;
- and the Play/continue button in the input toolbar.
That screenshot represents the checkpoint to which the conversation repeatedly returns.
It does NOT represent the actual last completed state, because substantial resumed work and additional work were completed afterward before the application was closed.
REQUEST:
Please investigate this as a session/history persistence and recovery issue.
Specifically, please determine:
-
Why a task that was successfully resumed and completed remains represented as an old interrupted/in-progress task after application restart.
-
Why conversation messages and completed work after the interrupted checkpoint disappear after a full restart.
-
Whether the supposedly missing post-recovery messages still exist in durable session storage.
-
Whether the workspace/file modifications produced by those completed turns remain intact.
-
Whether pressing the Play/Continue button on the restored old checkpoint is safe or could repeat already-completed operations.
-
Whether there is a supported method to restore/rebuild the latest durable conversation state without rerunning the completed task.
-
Whether this is a known Codex Desktop recovery/persistence bug triggered by an unexpected shutdown.
Please do not treat this simply as "the task was interrupted by a power outage."
The interrupted task WAS successfully resumed and completed.
The bug is that the successfully completed post-recovery conversation state disappears after the application is closed and reopened, and the UI returns to the obsolete interrupted checkpoint.
What steps can reproduce the bug?
-
Start a task in Codex Desktop and allow Codex to begin working.
-
While Codex is still actively working, the computer is unexpectedly shut down due to a power outage.
-
Restore power, restart the computer, and reopen ChatGPT/Codex Desktop.
-
Open the same conversation. The interrupted task is shown at the point where the shutdown occurred.
-
Instruct Codex to continue the interrupted task.
-
Allow Codex to continue working until the task is fully completed.
-
Confirm that the continuation messages, commands, file changes, verification steps, and final result are visible normally in the conversation.
-
Optionally give Codex another new instruction and allow that work to complete as well.
-
Completely close the ChatGPT/Codex Desktop application.
-
Reopen the application.
-
Open the same conversation again.
-
Observe that the completed post-recovery conversation history has disappeared and the conversation has reverted to the old checkpoint from the original power outage.
-
The old interrupted state is shown again with a Play/Continue button, even though that work had already been resumed and completed.
This happened more than once in the same conversation. New work completed after the recovery also disappeared again after fully closing and reopening the application.
What is the expected behavior?
After an interrupted task is resumed and successfully completed, the completed continuation should be permanently preserved in the conversation history.
Closing and reopening Codex Desktop should restore the latest completed conversation state, including all messages, commands, verification steps, and subsequent completed work.
The old interrupted checkpoint should no longer become active or appear resumable after the task has already been resumed and completed.
The UI should not show a Play/Continue action for an obsolete interrupted state that has already been successfully completed.
Additional information
The original power outage is not the main bug being reported.
I understand that an unexpected power loss can interrupt an active task.
The problem occurs AFTER recovery:
- I reopened Codex.
- I resumed the interrupted task.
- Codex successfully completed the task.
- The completed continuation was visible normally.
- I also submitted additional new work, which Codex completed successfully.
- I then fully closed the application.
- After reopening it, all of the completed post-recovery work disappeared from the visible conversation.
- The conversation returned to the old checkpoint from the original power outage.
- A Play/Continue button is shown again for that obsolete interrupted state.
This has happened repeatedly in the same conversation.
I am concerned that the visible conversation state and the actual workspace/files may now be inconsistent. If completed file changes remain on disk while Codex restores an old conversation checkpoint, pressing Play/Continue could potentially repeat commands or modifications that have already been completed.
I have attached a screenshot showing the stale interrupted checkpoint that reappears after restarting the application.
In the screenshot, the conversation shows the old execution state and a Play/Continue control. This is NOT the actual latest completed state. Substantial resumed work and additional work had already been completed after this point before the application was closed.
Please investigate whether the missing post-recovery conversation data still exists in durable session storage and whether this is a session persistence/history reconstruction issue after an unexpected shutdown.
Activity
github-actions commentedon Sep 8, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
ahmedsaber55 commentedon Sep 9, 2026
same problem on mac
ZYX20240308 commentedon Sep 10, 2026
same problem tonight
ZYX20240308 commentedon Sep 10, 2026
I ran into what appears to be the same issue on Windows and was able to recover the missing history without deleting the canonical rollout.
The important finding was that the conversation was not actually deleted. The rollout
.jsonlstill contained all later user/assistant messages and continued growing, while the derived paginated history inthread_history_1.sqlitewas stuck at an older point.The failure pattern in my rollout was:
The logs repeatedly showed:
PRAGMA quick_checkonthread_history_1.sqlitereturnedok, so this was not physical SQLite corruption. It was a divergence between the canonical rollout and the derived history projection.In my case there were actually two duplicate-ordinal boundaries in the same rollout. That turned out to matter.
How I diagnosed it
First, find the affected rollout and make backups of both:
Do not delete
.codex, the SQLite database, or the rollout before backing them up.I scanned the JSONL for duplicate top-level
ordinalvalues. Both bad boundaries had the same structure:Then I checked:
and:
The UI cutoff matched the last materialized turns/items, while the JSONL contained much newer records.
The most useful confirmation came from
logs_2.sqlite. Searching for:showed the exact mismatch:
Recovery that worked for me
This is an unsupported local recovery, so I would only do it after making byte-for-byte backups.
For a duplicate boundary, I determined the exact UTF-8 byte offsets of:
The safe projection position after skipping the duplicate metadata record is:
I did not delete or edit the duplicate record in the canonical JSONL.
For one duplicate boundary, advancing only the derived projection cursor past the verified duplicate
thread_settings_appliedrecord is sufficient.However, if the rollout contains multiple duplicate boundaries, there is an additional complication.
In my case I fixed the first duplicate and resumed the thread, but the SQLite cursor appeared not to move. The logs revealed that the projector had actually replayed thousands of records successfully, reached the second duplicate, failed there, and then rolled back the entire projection transaction.
So the state looked like this:
That initially made it look as if the first fix had failed, but it had not.
To recover a rollout with two bad boundaries, I used a two-stage replay:
After the final replay, I verified:
thread_itemsandthread_turnsalso contained the previously missing later history, and reopening Codex Desktop showed the conversation again.Important observations
The canonical rollout remained intact throughout the incident. The apparent "lost messages" were a history-projection failure, not transcript deletion.
Simply reopening Desktop did not repair it.
Running
codex resume <THREAD_ID>alone also did not repair it while the duplicate boundary was still present.Changing only
next_rollout_ordinalwas not reliable in my case. Advancing the byte offset past the verified duplicate metadata record, while preserving the expected next ordinal, was the important part.If there are multiple duplicate boundaries, a later duplicate can cause the whole catch-up transaction to roll back, making the persistent cursor look as though the earlier repair never ran. Checking
logs_2.sqliteis essential before assuming the first repair failed.I would strongly recommend that Codex eventually provide a supported repair command that can:
Related reports appear to include #41079, #41657, #41566 and #43742.
Hopefully this helps someone recover their history without deleting the rollout or rebuilding the entire Codex state.