Codex Desktop omits newer saved history segments and resumes from an obsolete checkpoint

What version of the Codex App are you using?

About Codex desktop version not captured. The currently running desktop-bundled executable reports codex-cli 0.155.0-alpha.9.2. A separate standalone CLI reports 0.147.0. Saved September 14 segment metadata records 0.154.0-alpha.6.2. These are distinct version observations, not evidence of a causal version mismatch.

What subscription do you have?

Not included in this public report; please correlate through the submitted in-app feedback.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0, x64.

What issue are you seeing?

On September 20, 2026, approximately 1:30-2:00 PM America/Chicago (CDT), a long-running task's visible history appeared to jump from current messages back to September 10 at 10:51 AM, omitting extensive work through September 19 at 10:41 AM. The task-read tool also returned current turns followed by older turns without the intervening work. The assistant initially relied on that obsolete checkpoint.

Read-only local inspection found four saved JSONL segments associated with the same canonical task ID, dated June 23, September 10, September 12, and September 14. Later segments contain paginated history and history_base references. A recovery export recovered 132 user/final-assistant messages from September 10-19. Newer work artifacts also remain present.

The account owner reports a similar occurrence in another task, but its identity and technical evidence have not yet been conclusively verified. This report therefore documents one investigated case and one reported recurrence, not two confirmed identical failures.

What steps can reproduce the bug?

Exact deterministic reproduction is not established. Observed sequence:

1. Continue a long-running desktop task across multiple days and saved history segments.
2. Revisit/continue it and observe that the visible chronology omits newer work.
3. Request recent history through the task-read tool and compare it with the local saved segments.
4. Observe newer saved user/assistant messages that are absent from the visible/retrieved chronology.

In-app feedback submission was confirmed with Feedback ID: 019ef557-e867-7c72-9ee6-59844e06661d.

Use of another device or surface around the incident, context-window utilization, and exact triggering action are not yet verified.

What is the expected behavior?

All saved conversation segments should remain accessible through the task timeline and history retrieval, and resumption should use the latest task state. If history cannot be loaded, the UI and assistant should receive an explicit warning rather than silently appearing to resume from an older checkpoint.

Additional information

The practical risk is repeating completed work or relying on outdated approvals. Local source history files were backed up without alteration. A readable recovery transcript restores access to content but does not repair the original task timeline. No application or database changes were made as part of recovery.

A pagination/history-chain/index-resolution issue is only a hypothesis. Please investigate using the submitted feedback and advise a supported, non-destructive repair. Raw conversations, company identifiers, screenshots, credentials, and local file paths are intentionally excluded from this public issue.

Start by comparing the four saved JSONL segments with the chronology returned by the task-read tool, using the canonical task ID and Feedback ID 019ef557-e867-7c72-9ee6-59844e06661d. Trace how paginated history and history_base references are resolved. Done means newer saved segments remain visible and retrievable, resumption uses the latest state, or an explicit warning is shown when loading fails.