Codex Desktop loses completed post-recovery conversation after restart and restores stale interrupted checkpoint

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:

1. Codex was actively working on a task.

2. A power outage unexpectedly shut down the computer while the task was still running.

3. After power was restored, I reopened ChatGPT/Codex.

4. The conversation correctly showed the task at the interrupted point.

5. I explicitly instructed Codex to continue the interrupted work.

6. Codex continued working.

7. Codex performed the remaining work and eventually completed the task.

8. The completed continuation was visible normally in the conversation.

9. I then gave Codex another separate instruction for additional work.

10. Codex also performed that additional work successfully.

11. The new messages, commands, changes, verification steps, and final result were visible normally.

12. I completely closed the ChatGPT/Codex application.

13. When I reopened the application, BOTH sets of completed post-recovery work had disappeared from the conversation.

14. The conversation had reverted again to the old checkpoint from the original power outage.

15. 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:

1. The recovered continuation should become part of the permanent conversation history.

2. The final completed task state should replace the old interrupted/in-progress state.

3. New messages and work performed afterward should also persist normally.

4. Closing and reopening the application should restore the latest completed conversation state.

5. An old interrupted checkpoint should NOT become active again after the task has already been resumed and completed.

6. 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:

1. Start a Codex task.
2. Unexpectedly terminate the machine/application while Codex is actively working.
3. Restart the machine.
4. Reopen Codex.
5. Resume the interrupted task.
6. Allow Codex to finish successfully.
7. Confirm that the completed continuation appears in the conversation.
8. Optionally submit another new task and allow it to finish.
9. Completely close the ChatGPT/Codex application.
10. Reopen the application.
11. 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:

1. Why a task that was successfully resumed and completed remains represented as an old interrupted/in-progress task after application restart.

2. Why conversation messages and completed work after the interrupted checkpoint disappear after a full restart.

3. Whether the supposedly missing post-recovery messages still exist in durable session storage.

4. Whether the workspace/file modifications produced by those completed turns remain intact.

5. Whether pressing the Play/Continue button on the restored old checkpoint is safe or could repeat already-completed operations.

6. Whether there is a supported method to restore/rebuild the latest durable conversation state without rerunning the completed task.

7. 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?

1. Start a task in Codex Desktop and allow Codex to begin working.

2. While Codex is still actively working, the computer is unexpectedly shut down due to a power outage.

3. Restore power, restart the computer, and reopen ChatGPT/Codex Desktop.

4. Open the same conversation. The interrupted task is shown at the point where the shutdown occurred.

5. Instruct Codex to continue the interrupted task.

6. Allow Codex to continue working until the task is fully completed.

7. Confirm that the continuation messages, commands, file changes, verification steps, and final result are visible normally in the conversation.

8. Optionally give Codex another new instruction and allow that work to complete as well.

9. Completely close the ChatGPT/Codex Desktop application.

10. Reopen the application.

11. Open the same conversation again.

12. Observe that the completed post-recovery conversation history has disappeared and the conversation has reverted to the old checkpoint from the original power outage.

13. 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.

Start with the Codex Desktop conversation and the reproduction sequence in this issue: interrupt an active task, resume it, complete further work, restart the application, and inspect the restored state. Investigate whether the post-recovery messages and work are durably retained, and consider the issue complete when reopening restores the latest completed conversation without exposing the obsolete checkpoint.