Repository navigation
Codex App task history disappears after durable rollout ordinal mismatch #41986
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.825.6671.0
What subscription do you have?
ChatGPT paid individual plan (exact tier not shown in Codex App)
What platform is your computer?
Windows 10.0.26200 (Windows 11 Core), x64
What issue are you seeing?
The Codex App stops displaying later turns from long local tasks even though the underlying rollout JSONL still contains them.
For one affected task, the UI stops at an older message and reports no additional history. Later prompts and completed agent turns remain present in the local rollout file, but they are absent from the app UI and from the thread-history API.
Local logs repeatedly report:
failed to project durable rollout
thread history projection expected ordinal 2143, got 2142
A second task shows the same failure with expected ordinal 2773, got 2772.
No prompt contents, credentials, or private files are included in this report.
What steps can reproduce the bug?
- Work in a long-lived local Codex App task over multiple days.
- Interrupt or resume a long-running turn and continue using the same task.
- Continue sending prompts; the agent completes the work and the rollout JSONL continues to grow.
- Reopen the task in the Codex App.
- Observe that the visible conversation ends at an older turn. Scrolling cannot load later turns.
- Read the task through the app-server thread API: it returns the same old turns with hasMore: false.
- Inspect the local rollout JSONL: the missing user and assistant messages are still present.
Affected thread IDs:
- 01a04f34-f354-7563-af67-7607d666c94a
- 01a04f9d-1037-7923-ba15-5532841a0f94
The first affected task logged 380 durable-projection failures; the second logged 390.
codex migrate-rollouts --thread --json --verbose reports already_paginated for both tasks, so the supported migration command does not repair them.
What is the expected behavior?
Every successfully saved local turn should remain visible after reopening a task. If the durable history projection becomes inconsistent, Codex should rebuild it from the intact rollout JSONL or provide a supported repair/reindex command. The UI must not report hasMore: false while later durable rollout events exist.
Additional information
Read-only diagnostics:
- codex doctor --all --no-color reports healthy SQLite integrity but thread inventory issues.
- 4 active and 3 archived rollout files are missing from the state DB.
- 5 duplicate rollout thread IDs are reported.
- Project migration state shows projects migrated while thread assignments are not completed.
- The affected rollout files themselves remain readable.
- Reopening, changing models, and resuming the task do not restore the missing turns.
- A newer desktop build (26.831.1138.0) was reported as available during diagnosis.
This appears to be a projection/index consistency bug rather than loss of the source conversation data.
Activity
github-actions commentedon Sep 1, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Nevod-g commentedon Sep 1, 2026
Additional updater information:
I attempted to update Codex, but the app reports that it is up to date.
The desktop logs show the following version mismatch:
26.825.6671.026.831.1138.0Codex checks the Windows Store package
OpenAI.Codex, but the update check completes with:canSilentlyDownload=true completed=false hasUpdate=false overallState=NoUpdatesThis happened repeatedly. Therefore, the newer build is visible to Codex diagnostics/manifest checking but is not currently being offered by the Windows Store to this device or account.
I have not reinstalled Codex or deleted the
.codexdirectory because it contains the intact rollout files associated with the missing task history.ashjo42 commentedon Sep 2, 2026
New Windows recurrence on Codex App 26.831.1445.0 (Pro), Codex CLI 0.145.0, Microsoft Windows NT 10.0.26200.0 x64.
Affected thread:
01a03f1a-375a-70d1-a465-2a125ebd7a16The App again stopped showing the later turns of a long-lived local task, while the missing user/assistant events remain readable in the local rollout JSONL. This thread is split across five rollout files; the final segment is about 192 MB and still contains the latest missing turns.
Read-only
codex doctor --all --no-colorreports healthy SQLite integrity, but 6 active rollout files are missing from the state DB and 5 duplicate rollout thread IDs exist. Four of the missing-active samples are continuation segments for the affected thread. Rollout scan errors are 0 and malformed filenames are 0.No session JSONL, session index, or SQLite files were edited, migrated, replaced, or deleted. This looks like the same projection/inventory-consistency family: source conversation data is intact, but the UI/history projection is incomplete. A supported rebuild/reindex path from the append-only rollout files is still needed.
ex37 commentedon Sep 6, 2026
Additional macOS occurrence with closely matching evidence. Diagnostics used the desktop's bundled Codex engine 0.153.4 on macOS arm64; this is the engine version, not the desktop About-dialog version.
The desktop UI stops at a September 5 turn even though the saved continuation contains September 6 messages. Fully quitting/reopening the desktop does not restore them. CLI resume works once the desktop releases its active-writer lock, but returning to the desktop still shows the old endpoint.
Verified storage and API evidence
thread_history_projection_statestops atnext_rollout_byte_offset = 22668577,next_rollout_ordinal = 5625.event_msg/token_count, thenevent_msg/thread_settings_applied. The saved projection byte offset is exactly the start of the second record.thread/turns/listreturns an old latest turn starting at ordinal 5613, despite many later saved turns.## My request for Codex:wrapper discussed in another missing-chat workaround.This is consistent with the ordinal/projection failure described here. We have not established what produced the duplicate ordinal or captured a matching projection-error log, so the precise causal mechanism remains unconfirmed. There is no deterministic clean-room reproducer yet.
Recovery experiment (isolated copy only)
An isolated recovery test consolidated the intended rollout lineage and used the bundled engine's native legacy-to-paginated migration to rebuild history. After aligning the resulting rollout filename with its projection key, the paginated API returned both the original first turn and the latest September 6 turn.
The rebuilt index contained 354 turns and all 4,155 distinct completed items from the intended source lineage, verified by
(turn_id, item_id)reconciliation with zero missing items. A scoped installer was also tested on a disposable database copy. The live desktop repair has not yet been confirmed.This is diagnostic evidence, not a recommendation for users to edit internal history files or enable an experimental migration. An official per-task repair/reindex operation, plus a visible error when saved history cannot be projected, would be valuable.
No raw conversations, tool outputs, databases, private project paths, or full task identifiers are attached.
daffamzidan commentedon Sep 8, 2026
Additional macOS occurrence of the same visible-history / persisted-rollout discrepancy, reported at the affected user's request. The ordinal-mismatch root cause in this issue has NOT been confirmed for this occurrence.
Environment:
Observed:
Expected:
Previously saved user messages and assistant responses should remain accessible in the task UI. History retrieval should not report hasMore=false while later persisted messages are omitted.
This was not reproduced from a clean session, and the exact onset and root cause are unknown. No session files or databases were modified during diagnosis. No private transcript, raw logs, artwork, account details, local usernames, or workspace paths are included in this public comment.
andronov-oleg commentedon Sep 8, 2026
Additional Windows recurrence with the same visible-history / intact-rollout symptom. The ordinal-mismatch root cause has NOT been confirmed for this occurrence.
Environment:
Observed:
Reindex experiment:
Additional observation:
Expected: all saved user and assistant turns should remain visible, and a clean history-index rebuild should recover them from intact rollout JSONL files. No raw conversations, server addresses, credentials, local usernames, private paths, databases, or full task IDs are included here.
andronov-oleg commentedon Sep 8, 2026
Follow-up from the same Windows occurrence:
codex doctor --all --no-colorcompleted with Codex Doctor v0.153.4. The only failing check wasTERM=dumb, caused by running the command in a non-interactive terminal; this is unrelated to the missing history.Relevant results:
This adds an important distinction to the earlier evidence: the doctor now reports healthy databases and a fully consistent rollout inventory, while the two affected tasks still expose incomplete or empty projected history in the UI/API. So the current
doctorchecks do not detect this content-level projection failure. Full output and private local paths are intentionally omitted.metze09 commentedon Sep 9, 2026
Additional Windows recurrence, observed September 9, 2026. The ordinal-mismatch root cause in this issue has not been independently confirmed for this occurrence.
Environment:
Observed:
turns: [],nextCursor: null, andhasMore: false.replacement_historyarrays of 115 and 144 entries.Expected: all persisted user and assistant turns should remain visible, or Codex should offer a supported per-task reindex/rebuild operation. No transcripts, raw logs, task IDs, account details, local usernames, private paths, or project content are included in this comment.
VictorBezak-4Minds commentedon Sep 9, 2026
Additional evidence from macOS, observed September 9, 2026. The visible-history symptoms and saved-log/history-tool discrepancy match this report, although an ordinal mismatch has NOT been confirmed in this case.
Environment:
Observed sequence:
Read-only verification:
Expected: saved user and assistant exchanges remain accessible when reopening the task. If the displayed history cannot be reconstructed, show an explicit error or provide supported recovery instead of silently presenting incomplete history as complete.
No session files, private project content, credentials, or full transcripts are attached. A deterministic minimal reproduction and the precise root cause are not yet established.