Completed messages missing from task history: duplicate rollout ordinal blocks history indexing

What version of the Codex App are you using (From “About Codex” dialog)?

26.901.51231 (build 8109), verified from installed app metadata. Affected task cli_version: 0.149.0-alpha.4.3.

What subscription do you have?

ChatGPT Pro (recently upgraded)

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

Completed messages from September 8 are missing from an existing task's displayed history, even though they remain intact in its saved local transcript. The app and read_thread tool stop at September 2. Quitting and reopening the app and navigating directly to the task did not resolve this.

At least 34 assistant message entries from September 8 were recovered from the saved JSONL, including a completed reply at 2026-09-08T16:55:16.713Z. Task metadata correctly reports activity through that time.

Read-only diagnostics found a duplicate rollout ordinal at the exact point where history projection stops. Repeated warnings say:

failed to project durable rollout for 01a03acc-0d99-76c0-b82f-967289222782: thread-store internal error: thread history projection for 01a03acc-0d99-76c0-b82f-967289222782 expected ordinal 1720, got 1719

This blocks access to completed professional work. I just upgraded to Pro, and silently losing access to completed conversation history is a serious reliability problem.

What steps can reproduce the bug?

1. Open the existing affected task: 01a03acc-0d99-76c0-b82f-967289222782.
2. Check the latest displayed messages. The visible/readable history ends around September 2, despite completed work on September 8.
3. Quit and reopen the app, then open the same task. The later messages remain absent.
4. Inspect the saved transcript and history projection state read-only. The September 8 messages exist in the transcript but have not been indexed.

The original trigger that produced the duplicate ordinal is unknown. This reproduces the persisted failure on the affected task, not a verified clean-install reproduction.

Confirmed sequence boundary (physical lines are 1-based):

• Line 1720, byte offset 14006004: ordinal 1719, event_msg/token_count, 2026-09-02T19:13:36.627Z.
• Line 1721, byte offset 14006878: ordinal 1719 again, event_msg/thread_settings_applied, 2026-09-02T19:14:24.496Z.
• Following entry: ordinal 1720, event_msg/task_started.

thread_history_projection_state is stuck at next_rollout_byte_offset=14006878 and next_rollout_ordinal=1720. The latest thread_items ordinal is 1717. The latest indexed thread_turns entry starts September 2 at rollout ordinal 1627 and is still marked inProgress.

History mode: paginated. No original transcript or application database was modified during diagnosis.

What is the expected behavior?

All durably saved messages should remain accessible after reopening a task. History indexing should recover safely from a sequence inconsistency or show a clear, actionable error instead of silently displaying an incomplete conversation.

Please provide a supported repair/reindex procedure that restores the complete task without losing its substantive messages, investigate the duplicate ordinal, and prevent recurrence.

Additional information

In-app feedback was successfully submitted with diagnostics.
Feedback ID: 01a03acc-0d99-76c0-b82f-967289222782

A local backup of the transcript and a readable export of September 8 assistant replies have been preserved. Private conversation contents, CRM data, credentials, and full raw logs are intentionally omitted from this public report.

Please escalate this history-integrity failure to engineering and provide a recovery path. Restarting has already been tried without success.

I also request consideration of a subscription credit or a complimentary usage reset for the disruption and the time and usage spent diagnosing and recovering work that should have remained accessible, especially immediately after upgrading to Pro. If account compensation cannot be handled through this issue, please direct me to the appropriate support team and reference the feedback ID above.

No source files or tests are named. Start by examining the saved JSONL and thread_history_projection_state around lines 1720–1721 and the duplicate ordinal, then trace the history projection path. Done means the complete durable history is accessible after reopening and sequence inconsistencies produce recovery or an actionable error.