Windows desktop history remains stale across two duplicate ordinal boundaries; offline cursor adjustment reaches a second projection failure

Summary

Codex Desktop on Windows repeatedly shows a long-running conversation only up to an older September 2 checkpoint after reopening. Later messages are still present in the durable local rollout. Updating and fully restarting the desktop app did not restore the visible history.

Related: #42027, #42197, #43124, #43765. This report adds a measured case with TWO duplicate ordinal boundaries and an unsuccessful, disclosed offline cursor intervention.

Environment

• Windows desktop app; exact desktop UI version not verified.
• Observed bundled command runner: 0.153.4 (not asserted to be the desktop app version).
• Long-lived local task with images and tool output.
• Snapshot scanned on September 9, 2026: 4,300,255,255 bytes and 107,625 complete JSONL lines.

Verified evidence

The history reader returned the same old checkpoint shown by the UI. Logs initially repeated:

codex_thread_store::local::live_writer:
failed to project durable rollout for <redacted-thread-id>:
thread-store internal error: thread history projection ...
expected ordinal 23088, got 23087

A bounded-memory read-only sequence scan found exactly two ordinal discontinuities in that snapshot. Different records share the same ordinal:

1. Ordinal 23087 at byte 918377107, then ordinal 23087 again at byte 918377929. The later event is thread_settings_applied.
2. Ordinal 89313 at byte 3886234772, then ordinal 89313 again at byte 3886235585. The later event is task_started.

These are distinct events, not a claim of byte-identical duplicates. Other observed numbered records were sequential. Later user/assistant message text was verified in the raw transcript; no claim is made that every message was forensically validated.

Intervention disclosed

After backing up the transcript and taking consistent SQLite snapshots, an offline script changed only this thread's projection byte offset from 918377929 to 918381433, retaining next_rollout_ordinal=23088. That is the measured start of ordinal 23088. The script used exact-state guards, transaction/readback and refused to run while Codex processes were active.

The UI STILL did not recover. Subsequent logs now report:

expected ordinal 89314, got 89313

The persisted projection cursor remains at the first corrected position. Catch-up appears to encounter the second collision before persisting progress, but transaction internals have not been verified.

No original rollout records have been deleted, rewritten or renumbered. Further ad-hoc skipping has been stopped. The issue predates the cursor intervention.

Expected / request

Please provide a supported per-thread recovery/reindex path that preserves both distinct records at each duplicate ordinal boundary and all later messages. Also investigate how reused ordinals are created and why one collision prevents all subsequent history from appearing.

Exact triggering steps for creation of the collisions are unknown. Reopening the already-affected task reliably reproduces the stale-history symptom.

Privacy

Submitted with the owner's authorization. No actual conversation content, customer/financial data, screenshots, credentials, private filesystem paths, original transcript, raw databases or full logs are attached. Private backups remain local.

Start with the codex_thread_store::local::live_writer projection errors and the per-thread projection cursor, using the reported duplicate ordinals and SQLite snapshots as the investigation anchors. Reproduce reopening the affected Windows task and determine how recovery can preserve both records at each collision and all later messages; done means a supported reindex path restores the complete visible history.