Skip to content

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

Open

Description

@zollo14

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.

Activity

  1. added
    appIssues related to the Codex desktop app
    on Sep 8, 2026
  2. added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Sep 8, 2026
  3. ahmedsaber55 commented on Sep 9, 2026

    @ahmedsaber55

    same problem on mac

  4. ZYX20240308 commented on Sep 10, 2026

    @ZYX20240308

    same problem tonight

  5. ZYX20240308 commented on Sep 10, 2026

    @ZYX20240308

    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 .jsonl still contained all later user/assistant messages and continued growing, while the derived paginated history in thread_history_1.sqlite was stuck at an older point.

    The failure pattern in my rollout was:

    ordinal N      event_msg / token_count
    ordinal N      event_msg / thread_settings_applied   <-- duplicate
    ordinal N+1    event_msg / task_started
    

    The logs repeatedly showed:

    failed to project durable rollout
    thread history projection expected ordinal N+1, got N
    

    PRAGMA quick_check on thread_history_1.sqlite returned ok, 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:

    ~/.codex/sessions/.../rollout-....jsonl
    ~/.codex/thread_history_1.sqlite
    

    Do not delete .codex, the SQLite database, or the rollout before backing them up.

    I scanned the JSONL for duplicate top-level ordinal values. Both bad boundaries had the same structure:

    token_count                 ordinal N
    thread_settings_applied     ordinal N
    task_started                ordinal N+1
    

    Then I checked:

    SELECT
        next_rollout_byte_offset,
        next_rollout_ordinal
    FROM thread_history_projection_state
    WHERE thread_id = '<THREAD_ID>';

    and:

    SELECT
        COUNT(*) AS item_count,
        MAX(rollout_ordinal) AS max_item_ordinal
    FROM thread_items
    WHERE thread_id = '<THREAD_ID>';

    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:

    failed to project durable rollout
    expected ordinal
    

    showed the exact mismatch:

    expected ordinal N+1, got N
    

    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:

    offset A: ordinal N     token_count
    offset B: ordinal N     thread_settings_applied   <-- duplicate
    offset C: ordinal N+1   task_started
    

    The safe projection position after skipping the duplicate metadata record is:

    next_rollout_byte_offset = C
    next_rollout_ordinal     = N+1
    

    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_applied record 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:

    SQLite cursor: still at first repaired boundary
    
    logs:
    expected ordinal <second N+1>, got <second N>
    

    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:

    1. Back up the complete rollout and projection DB.
    
    2. Repair the cursor past duplicate #1.
    
    3. Temporarily expose only the valid JSONL prefix ending immediately
       after the valid token_count at duplicate #2.
    
    4. Resume the thread.
    
       This allows the projection from duplicate #1 up to duplicate #2
       to commit successfully.
    
    5. Confirm that:
       next_rollout_byte_offset == temporary file length
       next_rollout_ordinal     == ordinal after duplicate #2
    
    6. Restore the original, byte-identical full JSONL from backup.
    
    7. Advance the projection byte offset past duplicate #2's
       thread_settings_applied record while keeping the expected
       ordinal at N+1.
    
    8. Resume again.
    
    9. Verify that the projection cursor reaches the full JSONL EOF.
    

    After the final replay, I verified:

    next_rollout_byte_offset == full rollout file size
    next_rollout_ordinal     == final ordinal + 1
    

    thread_items and thread_turns also 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_ordinal was 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.sqlite is essential before assuming the first repair failed.

    I would strongly recommend that Codex eventually provide a supported repair command that can:

    detect duplicate/regressed rollout ordinals
    verify that the conflicting record is safe metadata
    re-anchor the projection byte offset
    replay the history transactionally
    report whether the canonical transcript is intact
    

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions