[Windows Desktop] Interrupted initial task can orphan a completed paginated rollout and show only the first prompt

What version of Codex is running?

• ChatGPT Desktop / Codex on Windows
• Affected rollout writers:
  • 0.150.0-alpha.8
  • 0.154.0-alpha.6.2
• Local tasks with history_mode: "paginated"

What issue are you seeing?

Some local Codex Desktop tasks reopen with only the initial user prompt visible. The task can look like its complete conversation was deleted, but the full transcript remains in a separate rollout JSONL file on disk.

This is not a SQLite corruption issue. PRAGMA integrity_check returned ok.

Confirmed storage pattern

For each affected task, the local session directory contained:

1. A short base rollout with the root session ID in its filename.

   • It ended with turn_aborted.
   • It contained only the initial user request or an early partial turn.

2. A much larger later rollout whose filename included the same root session ID plus a turn-ID suffix.

   • It contained the missing completed conversation and a task_complete event.
   • Its session_meta.session_id and session_meta.id matched the root task ID.
   • It did not include history_base metadata.
   • Its top-level ordinal values restarted at 0, rather than continuing from the base rollout.

The Desktop task-history reader displayed only the short aborted base rollout and reported hasMore: false; it did not discover the later complete rollout.

This occurred in four independent local tasks, including substantive multi-hour tasks, not only a disposable test.

Sanitized example

base rollout
  session_id = A
  records = 6
  ordinals = 0..5
  terminal event = turn_aborted
  size = 24 KB

later rollout
  filename = rollout-...-A_<turn-id>.jsonl
  session_meta.session_id = A
  session_meta.id = A
  history_base = absent
  records = 1,094
  ordinals = 0..1,093
  terminal event = task_complete
  size = 7.8 MB

Desktop read of A
  hasMore = false
  visible content = initial user request only

Other affected examples had the same shape: short aborted base rollouts of 11 and 50 records, followed by complete 4.7 MB and 4.1 MB rollout files respectively, again without history_base and with ordinal zero restarts.

Expected behavior

After an interrupted initial turn, a later continuation/retry that keeps the same root session_id must be written with valid lineage metadata and must remain visible when the task is reopened.

In particular, the writer should either:

• write a valid history_base pointing to the correct prior rollout and ordinal/byte boundary; or
• create a distinct task/session identity rather than reusing the root ID; or
• atomically promote the completed replacement rollout as the active base rollout.

The history reader should also detect this recoverable pattern: same root session_id, a later complete suffixed rollout, and a short aborted base. It should prefer the complete record or show a recoverable-history warning rather than silently presenting only the stale initial prompt.

Actual behavior

The app silently projects the first aborted rollout and hides the later completed transcript. Users can reasonably conclude that completed work has been lost.

Local workaround used

Before any change, the original base and continuation files were copied to a separate backup directory.

For each confirmed affected task, replacing the short base rollout contents with the corresponding intact complete continuation restored the visible history after restarting the desktop client.

This is only a local recovery technique, not a safe general user workflow. The app should provide a supported reindex/reconcile/recover action and should not require users to manually alter rollout files.

Related issues

This appears related in symptom but differs in the stored evidence from:

• #42269 — older branch selection after editing prompts; the affected branches there include history_base.
• #41986 and #44035 — stale or incomplete visible history while later durable data remains.
• #43422 — task/rollout identity mismatch.
• #41608 — paginated rollout catalog parity.

The specific signature here is a later completed rollout that reuses the root session ID but has no history_base and restarts ordinals at zero after a short aborted base rollout.

Privacy

No raw rollout files, task IDs, local usernames, absolute paths, prompts, command output, or project contents are attached. I can provide sanitized metadata or diagnostics privately if useful.

Start by tracing the paginated task-history reader and rollout writer for interrupted initial turns, focusing on the short aborted base rollout and later suffixed rollout with the same session ID. Done means the completed continuation remains visible or the history is explicitly recoverable, with coverage for the missing-history_base and restarted-ordinal pattern described here.