[Windows][26.825.6671.0] Resuming unfinished threads reuses rollout ordinals and permanently stalls paginated history

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

26.825.6671.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

On Windows Codex Desktop, resuming an unfinished or interrupted local thread can assign a duplicate top-level rollout ordinal. The duplicate permanently stalls the paginated thread-history projection.

After the failure, the desktop UI displays only an old prefix of the conversation. Later user messages, assistant messages, tool outputs, and completed turns appear to have been deleted after reopening Codex. Forensic inspection shows that the canonical rollout JSONL remains intact, remains parseable, and continues to receive later records.

This is not canonical transcript deletion or physical SQLite corruption. It is a persistent divergence between the durable rollout and the derived paginated history projection.

Scope of the local integrity scan

A read-only scan covered 15 local Codex rollout files:

Total rollout files inspected:       15
Rollouts with malformed JSON:         0
Rollouts with ordinal discontinuity:  2
Unaffected rollouts:                 13

The same failure occurred in two independent threads. Each affected rollout contained exactly one duplicated top-level ordinal.

Affected thread A

Physical line 322:
  ordinal: 321
  type: event_msg
  payload.type: token_count

Physical line 323:
  ordinal: 321
  type: event_msg
  payload.type: thread_settings_applied
  duplicate: yes

Physical line 324:
  ordinal: 322
  type: event_msg
  payload.type: task_started

Projection state at the failure boundary:

next_rollout_byte_offset = 2831319
next_rollout_ordinal     = 322

Repeated projector error:

failed to project durable rollout:
thread history projection expected ordinal 322, got 321

The projection database contains only the original turn, still marked inProgress, even though the canonical rollout contains later user/assistant records and multiple later task_complete events.

Affected thread B

Physical line 1255:
  ordinal: 1254
  type: event_msg
  payload.type: token_count

Physical line 1256:
  ordinal: 1254
  type: event_msg
  payload.type: thread_settings_applied
  duplicate: yes

Physical line 1257:
  ordinal: 1255
  type: event_msg
  payload.type: task_started

Projection state at the failure boundary:

next_rollout_byte_offset = 4800482
next_rollout_ordinal     = 1255

Projector error:

thread history projection expected ordinal 1255, got 1254

The rollout continues beyond this point, but the desktop history does not advance.

Common failure signature

unfinished/interrupted turn
→ token_count with ordinal N
→ later thread_settings_applied also receives ordinal N
→ task_started receives ordinal N+1
→ history projector expects N+1 but reads N
→ projection permanently stops
→ canonical rollout continues growing
→ later conversation history becomes inaccessible in the UI

Additional observations:

• Every inspected JSONL line is valid JSON.
• No canonical user or assistant record was found physically truncated.
• PRAGMA integrity_check returns ok for the relevant SQLite databases.
• The projection cursor stops exactly at the duplicated metadata record.
• Restarting Codex does not reconcile or rebuild the stalled projection.
• Continuing to use an affected thread keeps adding canonical records, but they remain absent from rendered history.
• The projection error is logged repeatedly for subsequent writes.
• The issue is thread-specific rather than global: the other 13 local rollouts are structurally normal.
• No manual modification was made to the canonical rollout or projection databases during diagnosis.

User impact

This is a high-impact data-integrity and auditability issue rather than a cosmetic rendering problem. Completed messages, tool outputs, and implementation details become inaccessible. Users may repeat already completed system operations because the UI suggests they never occurred, while continued work is appended to a transcript the UI can no longer render. No visible warning explains that the durable transcript and displayed history have diverged.

What steps can reproduce the bug?

The failure is not yet deterministically reproducible, but both independent occurrences are consistent with this sequence:

1. Open a local thread using paginated history.
2. Start a turn that performs tool calls or other long-running work.
3. Allow the turn to remain unfinished or be interrupted without a normal task_complete event.
4. Close, restart, or otherwise reconnect Codex Desktop.
5. Resume the same thread and start another turn.
6. Inspect the rollout boundary between the unfinished turn and the resumed turn.
7. In affected cases, thread_settings_applied reuses the preceding token_count ordinal.
8. Reopen the thread or inspect its rendered history.
9. Observe that the UI remains frozen at the last successfully projected record while the canonical rollout continues to grow.

The problem occurred in two independent threads, so it does not appear to be isolated corruption of a single conversation.

A minimal deterministic reproduction has not been attempted by forcibly terminating Codex because doing so could damage additional user data.

What is the expected behavior?

• Every top-level record in a paginated rollout receives a unique, monotonically increasing ordinal.
• On resume, the writer derives the next ordinal from the durable rollout tail or another authoritative persisted source.
• An unfinished turn is explicitly recovered, closed, or marked interrupted before a new turn begins.
• A verified duplicate metadata record does not make all subsequent valid conversation history inaccessible.
• Startup detects divergence between the canonical rollout and thread_history_projection_state and safely reconciles or rebuilds the projection.
• If automatic recovery is impossible, Codex displays an actionable integrity error instead of silently showing stale history.
• A supported history diagnostic/repair command is available.

Additional information

Environment

• Codex App: 26.825.6671.0
• Codex CLI/app-server: 0.151.0-alpha.7.2
• Subscription: ChatGPT Plus
• Platform: Microsoft Windows NT 10.0.26200.0 x64

Related issues

This appears closely related to:

• #41079 — paginated history stalls on a duplicate ordinal while the rollout remains complete
• #41566 — duplicate ordinal after an unfinished turn permanently freezes projection
• #41475 — interrupted/rebooted Windows task leaves an orphaned turn and hides later messages
• #40630 — mid-session process exit followed by expected ordinal N, got N-1
• #41632 — Windows failure cascade including duplicate ordinals and missing history

The additional evidence in this report is:

• Reproduction on Codex App 26.825.6671.0.
• Reproduction in two independent local threads.
• A complete scan showing that only 2 of 15 local rollouts are affected.
• The same token_count → duplicated thread_settings_applied → task_started sequence in both cases.
• Clean JSON and SQLite integrity checks, isolating the failure to ordinal assignment and history projection rather than physical database corruption.

Suggested implementation safeguards

1. Serialize all writers that append to a paginated rollout.
2. Refresh and validate the durable rollout tail before assigning a new ordinal.
3. Treat thread_history_projection_state.next_rollout_ordinal as a consistency constraint during resume.
4. Detect the verified pattern where a metadata record reuses the immediately preceding ordinal.
5. Rebuild or reconcile derived history from the canonical rollout when startup detects a mismatch.
6. Add integrity checks for duplicate, regressed, and missing ordinals.
7. Provide a supported diagnostic and repair command that preserves the canonical transcript.
8. Add regression coverage for unfinished turns, interrupted tool calls, app restart during a turn, and thread resume after abnormal termination.

Diagnostic material available

Sanitized event windows, projection cursor state, byte offsets, projected turn/item counts, integrity-check results, and redacted log excerpts can be provided if requested.

Raw rollout files and unredacted logs are not attached because they may contain prompts, local paths, tool outputs, and other private information. This report intentionally excludes thread/session IDs, Windows account names, absolute filesystem paths, credentials, and conversation contents.

Start by tracing the paginated rollout writer and resume path alongside the thread-history projector, using the reported token_count → thread_settings_applied → task_started sequence as the first diagnostic case. Compare the durable rollout tail with thread_history_projection_state, then add coverage for interrupted turns and resume; done means duplicate ordinals no longer stall rendered history and divergence is detected or recovered.