[Windows][0.153.4] Duplicate thread_goal_updated ordinal stalls history projection; verified per-task recovery #45228

What version of the Codex App are you using?

Installed Windows package: OpenAI.Codex 26.903.8094.0 (queried from the package, not the About dialog).
The executable used by the running desktop app reports codex-cli 0.153.4. The affected thread also records 0.153.4 and history_mode=paginated.

What subscription do you have?

Not collected for this report.

What platform is your computer?

Windows x64; runtime reports Windows 10.0.26100.

What issue are you seeing?

A long-running local task appeared to lose recent conversation history after reopening the desktop app. The durable rollout still contained later user messages, assistant responses, and completed turns. Both the desktop's task-history API and its SQLite projection returned an older endpoint.

This adds a verified thread_goal_updated duplicate boundary and an isolated recovery test on 0.153.4 to related reports #41079, #41353, and #43142.

Sanitized evidence

A full scan of the canonical rollout found:

• 220,557,051 bytes and 12,473 complete, JSON-parseable lines.
• Exactly one non-increasing top-level ordinal transition.
• Later completed turns persisted through September 13, 2026.

The problematic boundary was written on September 8, 2026 (UTC):

The persisted projection cursor was:

next_rollout_byte_offset = 160165863
next_rollout_ordinal = 9233

It therefore pointed at the repeated ordinal 9232 while expecting 9233. The most recent projected turn was from September 8, even though later completed turns remained in the JSONL. The source thread was not archived.

The installed command:

codex migrate-rollouts --thread <redacted> --json

returned already_paginated, bytes_processed: 0; it did not repair this condition.

What steps can reproduce the bug?

Observed sequence, not a fresh deterministic reproduction of the original writer bug:

1. Continue a local, paginated task across multiple days with a long-running goal.
2. Reopen the desktop app and inspect that task.
3. Recent saved conversation rounds are absent; newest-first history reads also return an older turn.
4. Compare the canonical JSONL boundary above with the projection cursor.

The exact trigger that originally caused duplicate ordinal assignment is unknown. Concurrent writers, an update, or a crash have not been established as the cause.

Isolated recovery experiment

Before changing the live index:

1. Backed up the canonical rollout and copied only the affected task's state/history rows into an isolated Codex home, without credentials or user configuration.
2. Used the same installed 0.153.4 app-server executable. A history read reproduced the stale endpoint.
3. Advanced only that task's projection byte cursor from 160165863 to 160166627, keeping the expected ordinal at 9233. This passed the single duplicate goal-metadata record; no user/assistant record was skipped, and the source JSONL was untouched.
4. Resumed the task in the isolated home without starting a model turn, then read its history. Projection caught up to EOF:

next_rollout_byte_offset = 220557051
next_rollout_ordinal = 12472
thread_turns: 6 -> 21
thread_items: 3017 -> 3987

The three September 13 turns, including their available user/assistant summary messages and completed statuses, were readable. SQLite quick_check passed, and the canonical rollout SHA-256 was unchanged.

The validated projection rows were then installed transactionally for that task only. The live history API now returns the latest completed turn IDs and timestamps; however, that already-running app's tool still returns empty item arrays for those newly visible turns, despite the populated SQLite rows and successful isolated reader. A full UI restart has not yet been validated. This residual behavior could be cache-related, but that is an inference.

This manual, backed-up recovery is diagnostic evidence, not a general recommendation to edit a live Codex database.

What is the expected behavior?

• Prevent reuse of durable rollout ordinals.
• Reconcile an already-stalled projection safely, with special handling for metadata records that do not represent conversation messages.
• Provide a supported per-task repair/reindex command for already-paginated tasks.
• Warn users when visible history is behind durable history instead of silently showing an apparently successful but incomplete restore.
• Refresh any loaded history caches after recovery.

Additional information

The tagged 0.153.4 source returns an error on ordinal < next_ordinal in thread_history_materialization.rs. That matches the observed cursor boundary, but does not prove which writer path produced the duplicate.

No private task IDs, paths, prompts, goals, conversation text, credentials, raw rollouts, or raw logs are attached.