[Windows Codex App] Task repeatedly returns to stale history: duplicate ordinal blocks projection

Summary

P1 — Persistent task-history projection failure: an existing Windows Codex Desktop task repeatedly appears to return to an old state despite newer user messages and assistant responses being exchanged. Read-only diagnostics confirm later events remain in the durable rollout, but history projection is stuck at a duplicate ordinal. The origin of that duplicate is unknown; this report does not claim the newer messages were deleted.

Related: #43896 reports the same expected-ordinal failure on macOS. This report supplies a separate affected Windows session and exact projection boundary at the owner's request. Please link/deduplicate if appropriate.

Version / platform

• User-provided About dialog: Version 26.903.61454, Released 9 Sept 2026. The dialog is titled "About ChatGPT", identifies the app as "ChatGPT", and says "Powered by Codex & OWL".
• Separately observed Windows package: OpenAI.Codex, version 26.903.8094.0 (Get-AppxPackage). This differs from the About-dialog version; both are retained as distinct observations, not assumed to be equivalent.
• Affected rollout session metadata: originator: Codex Desktop, cli_version: 0.153.4 (session metadata, not an assertion about the currently bundled executable).
• OS: Microsoft Windows NT 10.0.26200.0, x64.
• Subscription: not collected.
• Affected session/thread ID: 01a08043-bb9e-7510-878f-6ae1b3f2d696.
• Observed/diagnosed: 2026-09-14, approximately 17:11–17:14 UTC.

Actual behavior

The user reports repeated returns to the same older conversation state after new messages and responses have been sent/received. Independently, read_thread with turnLimit: 1 returns the newest indexed turn as:

{
  "id": "01a080dc-334a-7ab3-af31-f586e256e048",
  "status": "inProgress",
  "startedAt": 1788868309,
  "completedAt": null
}

That turn is from September 8, while the transcript contains September 14 messages and tools. Thus the history API is observably stale, not merely an assistant misunderstanding of the latest prompt.

Evidence (read-only local inspection)

The approximately 54 MB JSONL rollout had 11,602 physical lines at one live snapshot. A scan found exactly one ordinal discontinuity:

Read-only SQLite query of thread_history_projection_state for this thread returns:

next_rollout_byte_offset = 9142965
next_rollout_ordinal     = 1644

The cursor is therefore stuck precisely at the duplicated ordinal. The latest indexed thread_turns row has rollout ordinal 1361 and the in-progress turn ID above.

Newer durable entries exist, for example:

line 11543, ordinal 11541: response_item/message/user
  2026-09-14T17:11:18.377Z
line 11576, ordinal 11574: response_item/message/assistant
  2026-09-14T17:12:24.680Z

The log database repeatedly records this error during new turn processing (context/path/model details redacted):

failed to project durable rollout for 01a08043-bb9e-7510-878f-6ae1b3f2d696:
thread-store internal error: thread history projection for
01a08043-bb9e-7510-878f-6ae1b3f2d696 expected ordinal 1644, got 1643

Reproduction scope

1. Continue the affected existing long-running task and exchange new messages.
2. Inspect its persisted history through the app's read_thread tool: the newest indexed turn remains the old September 8 in-progress turn.
3. Compare the read-only rollout and projection cursor: newer messages exist beyond the blocked ordinal, and new processing continues to produce the projection warning.

This reproduces the persisted history inconsistency in the affected task, not a deterministic clean-install recipe for creating duplicate ordinals. The user's repeated UI reset is reported; diagnostics did not force a restart or deliberately reproduce UI navigation/reset behavior.

Expected behavior / requested help

• Durably saved new turns should remain visible and retrievable without returning to stale history.
• A projection sequence error should surface an actionable error, not silently present incomplete history.
• Please provide a supported, non-destructive repair/reindex procedure preserving all messages and investigate how the duplicate thread_settings_applied ordinal arose.

Privacy and integrity

SQLite was opened with mode=ro and PRAGMA query_only=ON. No application database or transcript was edited, deleted, reset or repaired. The transcript was read while the task was active, so the final line count grows. No credentials, private source code, full conversation text, raw databases or unredacted logs are included. The session ID is a diagnostic correlation identifier, not a submitted-feedback receipt. No in-app feedback submission is claimed.

Start with the read-only rollout around byte offset 9142965 and the duplicate ordinal at physical line 1645, then compare it with the thread_history_projection_state row and the repeated projection error. Use read_thread with turnLimit 1 to verify the stale indexed turn. Done means identifying how the duplicate arose and defining a supported, non-destructive repair or reindex that preserves all messages.