[Windows][26.831.1445.0] App update/resume duplicates a rollout ordinal and hides later task history

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

OpenAI.Codex 26.831.1445.0 (the affected thread recorded codex-cli 0.151.0-alpha.7.2)

What subscription do you have?

ChatGPT paid individual plan (exact tier is not shown in the Codex App)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After a Codex App update/relaunch, a long-running local task appeared to have lost most of its conversation history. The raw rollout remained complete, but the paginated thread-history projection stopped at one duplicate top-level ordinal.

The app-server initially returned the stale history with no older page available, and a same-directory fork failed with:

failed to prepare paginated fork: thread-store internal error:
thread history projection for <redacted thread id> expected ordinal 7204, got 7203

The canonical rollout JSONL was about 45 MB and still contained all 19 user messages, including the first prompt and the latest prompt. A point-in-time scan found 15,865 valid JSON records and exactly one ordinal discontinuity:

Physical record index	Top-level ordinal	Record
7203	7203	event_msg/token_count
7204	7203	event_msg/thread_settings_applied
7205	7204	event_msg/task_started

The projection state was:

next_rollout_byte_offset = 33570350
next_rollout_ordinal     = 7204

That byte offset pointed exactly to the second ordinal-7203 record. All other ordinals in the snapshot were strictly sequential, and PRAGMA integrity_check returned ok.

This was transcript projection loss, not transcript deletion.

What steps can reproduce the bug?

The failure is intermittent, but this is the observed sequence:

1. Use a long-running local Codex App task with paginated history across many turns and tool calls.
2. Let the Codex App update/relaunch while the task has previously had an interrupted or long-lived turn.
3. Continue using the same task and add later turns.
4. Reopen the task after the update.
5. Observe that the UI stops at an older snapshot even though the rollout JSONL continues to contain later messages.
6. Attempt to fork the task; the fork fails with expected ordinal N+1, got N.

I did not intentionally force-kill the app for this occurrence. The duplicate appeared at a resume boundary: a thread_settings_applied record reused the preceding token_count ordinal, then task_started used the ordinal that the settings record should have used.

The affected thread ID and raw diagnostics are withheld from the public issue because they contain local task data, but they can be provided through a secure channel.

What is the expected behavior?

• Every durable rollout record should receive a unique, monotonically increasing ordinal across app updates, restarts, and resumed turns.
• A duplicate metadata/no-op record should not permanently block projection of all later valid conversation history.
• On startup, Codex should reconcile or rebuild an inconsistent projection from the intact canonical rollout.
• The UI should surface an actionable repair error instead of silently showing an incomplete transcript.
• A supported codex doctor repair/reindex command should be available for already affected tasks.

Additional information

A backup was taken before recovery. Without modifying the canonical JSONL, I advanced only the projection byte offset by 1,564 bytes past the duplicate thread_settings_applied record while keeping the expected ordinal at 7204.

After the next read triggered projection:

• paginated history returned hasMore: true;
• the projector caught up to the current rollout tail;
• 5,103 history items were indexed;
• all 19/19 user messages were queryable again;
• SQLite integrity remained ok.

This confirms that the later history was durable and that skipping this verified duplicate metadata record was sufficient for lossless recovery.

Related reports: #42027, #41079, #41566, #41986. The additional evidence here is recurrence on 26.831.1445.0 at an app update/relaunch boundary without an intentional force-kill, plus a byte-exact, no-JSONL-modification recovery.

No thread identifiers, absolute paths, prompts, credentials, or raw logs are included publicly.

Start by examining the app-server paginated thread-history projection and its rollout byte-offset and ordinal state around the duplicate thread_settings_applied record. Compare the canonical rollout JSONL with the SQLite projection and related reports #42027, #41079, #41566, and #41986. Done means resumed tasks retain later history, inconsistent projections are reconciled or rebuilt, and affected tasks have an actionable repair path.