[Desktop][Windows] Paginated thread history stalls on duplicate ordinal while rollout remains complete

Summary

On Windows Codex Desktop, one local paginated thread displayed only an older history snapshot although the canonical rollout JSONL still contained all later messages and the completed task. This was a local history-projection stall, not transcript deletion.

Environment

OS: Windows 11 x64
Installed Codex Desktop package: 26.820.9563.0
Thread-recorded runtime: codex-cli 0.149.0-alpha.4.1
History mode: paginated

Sanitized evidence

The rollout JSONL remained parseable and contained exactly one repeated ordinal: ordinal 2186 appeared twice.
The two records were event_msg/token_count and event_msg/thread_settings_applied.
thread_history_projection_state expected ordinal 2187 at the byte offset where the second ordinal-2186 record began.
The projection repeatedly logged an error equivalent to: expected ordinal 2187, got 2186.
The SQLite projection stopped at an earlier ordinal while later user/assistant records and task completion remained present in the rollout JSONL.
SQLite integrity checks were clean; there was no evidence of physical database corruption.
After backing up the files, advancing only the projection byte offset past the duplicate record while keeping the expected ordinal at 2187 allowed the projection to catch up. The canonical JSONL was not modified.

Expected behavior

When a paginated history projection encounters a duplicate boundary ordinal, Codex should reconcile or rebuild the projection from the canonical rollout, or safely skip a verified duplicate metadata record. It should not silently leave the UI permanently behind the durable transcript.

Likely cause

This appears related to duplicate ordinal assignment during restart/resume or concurrent app-server writers, combined with a projector that treats a lower ordinal as fatal and has no automatic recovery path. Related reports include #40109 and #40178. Issue #32198 is related to Windows paginated-history handling but appears distinct: it concerns legacy tool_search_output parsing/replay UI freezing, not duplicate ordinals or a frozen SQLite projection.

Requested fixes

Serialize rollout writers and refresh the durable tail before assigning paginated ordinals.
Detect byte-offset/ordinal mismatches on startup and rebuild or reconcile thread_history_*.
Provide a supported history repair/doctor command.
Surface an actionable error instead of silently showing stale history.

Privacy

No thread ID, absolute paths, prompts, conversation content, credentials, or raw logs are attached.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

[macOS Desktop] Reboot can switch app-server runtime and wedge paginated history at a duplicate ordinal #40178
Serialize concurrent rollout writers before assigning paginated ordinals #40109

Powered by Codex Action

Additional reproduction on Windows 10 build 19045, package 26.820.9563.0, desktop client 26.820.71523, app-managed backend codex-cli 0.150.0-alpha.8.

Read-only inspection of six affected local tasks confirms the same precise boundary pattern described in this issue: event_msg/token_count followed by event_msg/thread_settings_applied, both carrying the same top-level ordinal. The projection expects the next ordinal and stops updating.

Sanitized samples

Each row is a different task; all task identifiers and conversation content are omitted.

Sample	Projection expects	token_count ordinal	following thread_settings_applied ordinal
A	987	986	986
B	639	638	638
C	2523	2522	2522
D	672	671	671
E	368	367	367
F	810	809	809

Sample A's persisted projection checkpoint is:

{"next_rollout_byte_offset":11328572,"next_rollout_ordinal":987}

Immediately before that byte offset:

{"timestamp":"2026-08-27T18:59:09.760Z","ordinal":986,"type":"event_msg","payload":{"type":"token_count"}}

At that byte offset:

{"timestamp":"2026-08-27T19:00:00.849Z","ordinal":986,"type":"event_msg","payload":{"type":"thread_settings_applied"}}

These are field-reduced excerpts; other payload fields are intentionally omitted, not empty in the source.

The repeated error is:

codex_thread_store::local::live_writer
failed to project durable rollout for <redacted-thread>:
thread-store internal error:
thread history projection for <redacted-thread> expected ordinal 987, got 986

Durable data versus visible history

At approximately 05:21 local UTC+08:00 on 2026-08-28, sample A contained 1,827 valid JSONL records and 23 task_started events, while its projection had only 14 cached turns. Nine subsequent turns were not represented in that cache.
The last cached turn began at 02:58:13 local, but the canonical rollout continued recording later user/assistant activity.
By the 05:38–05:39 inspection, that rollout was 22,348,289 bytes and contained a newly written assistant progress message at 05:36:46. The projection was still at byte offset 11,328,572 / expected ordinal 987.
After restart, thread/resume at 05:37:02 again logged expected ordinal 987, got 986. Restart did not repair the projection.
Read-only SQLite quick_check(1) returned ok for both state_5.sqlite and thread_history_1.sqlite. This is a structural check, not a guarantee of semantic consistency.

There are also recurring authentication-triggered sign-outs on this machine; separate evidence is being added to #39189. The projection checkpoint had already stalled before the captured sign-outs. A sign-out/restart then makes the UI reload the old cached history, so recent conversation appears to have disappeared despite remaining in the raw rollout. We are not asserting permanent transcript deletion or that authentication caused the duplicate ordinal.

Requested investigation

Please investigate ordinal allocation across the token_count -> thread_settings_applied boundary and provide automatic safe reconciliation, or a supported history repair mechanism, plus an explicit stale-history warning instead of silently showing an old transcript.

We have not applied the manual byte-offset workaround in the opening report, changed affected rollout files, or patched the affected projection checkpoints. An official repair path would be preferable to users guessing which records are safe to skip.

No thread IDs, account information, local paths, prompts, source documents, credentials, raw log archives, or databases are included in this comment.

Fresh reproduction on a newer Windows Desktop build, with a higher-impact failure mode than stale history alone.

Environment

Windows 11 Home 10.0.26200 (build 26200)
Codex Desktop package: 26.825.3734.0
Bundled runtime: codex-cli 0.150.0-alpha.12.2
Local paginated Desktop thread

Sanitized sequence

At 2026-08-28 04:10:37Z, the rollout appended event_msg/token_count with ordinal 166.
The local app-server transport closed about three seconds later. The immediately preceding application error mentioned a missing custom-tool-call output.
After automatic recovery, at 04:10:53Z, event_msg/thread_settings_applied was appended with ordinal 166 again.
The JSONL remained parseable and had no ordinal gaps, but had exactly that one duplicate.
Every later durable projection attempt reported:
thread history projection ... expected ordinal 167, got 166
The global app-server then repeatedly terminated/restarted with Windows exit code 3221225786 (0xC000013A) — observed again around 04:14:38Z, 04:19:52Z, and 04:27:21Z.

The important additional impact is that this poisoned single thread does not only show stale history: the recurring global app-server restart interrupts active turns in other Desktop tasks as well. One separate task was observed being marked interrupted during recovery.

A read-only scan of nine recent session rollouts found only the active affected rollout with an ordinal defect (one duplicate, no gaps). The machine had ample free memory and no matching Windows Application Error/Hang or resource-exhaustion event, so this does not look like memory pressure or an OS crash.

The app had recently been reset; this thread and the duplicate were created after that reset, so reset/reinstall is not preventive.

Requested containment

Allocate the next rollout ordinal atomically across app-server restart/recovery.
Reconcile or rebuild a projection when a duplicate metadata boundary is detected.
Do not let one thread's projection failure terminate the global app-server or interrupt unrelated tasks.
Surface a repair/archive action for the poisoned thread.

No thread IDs, absolute paths, prompts, conversation content, call IDs, credentials, or raw logs are included here. A local observer is retaining privacy-sensitive incident bundles for private follow-up if maintainers request them.

Follow-up with local mitigation results and a remaining failure mode: the restart loop can be contained, but the originally poisoned thread still cannot display or continue follow-up turns.

Actions performed locally

All changes were preceded by local backups. No canonical rollout JSONL was modified.

Identified two affected paginated rollouts after subsequent restarts:
- Thread A had duplicate ordinal boundaries at 166 and later 448.
- Thread B had a duplicate ordinal boundary at 72.
Backed up each affected rollout and created a consistent SQLite online backup.
Applied a narrowly guarded projection-cursor repair only where all of these were true:
- projection expects N;
- previous and current rollout records are both N-1;
- the next record is exactly N;
- the conditional SQLite update still matches the original byte offset and expected ordinal.
Repairs applied:
- Thread A: byte offset 1,907,105 -> 1,908,709, expected ordinal remains 167.
- Thread B: byte offset 1,586,937 -> 1,588,523, expected ordinal remains 73.
SQLite PRAGMA quick_check returned ok.
Built a 1-second observer/guard that records app-server incidents and, on this exact verified duplicate-boundary signature only, backs up the rollout/database before advancing the projection byte offset. It never edits the rollout JSONL.
Tested the full guard in an isolated copy of the rollout and databases:
- simulated projection at duplicate 448;
- repaired offset 3,505,250 -> 3,506,854;
- retained expected ordinal 449;
- backup receipt created;
- database quick check remained ok.
Restarted only the Desktop app-server process so it would reload the updated database state.

Outcome

The mitigation partially worked:

Thread B recovered: its projection advanced from expected ordinal 73 to 192.
The global repeated-restart loop has not recurred since the controlled app-server restart.
Thread A remains permanently stale even after a fresh Desktop/app-server process.

Current sanitized Thread A state:

canonical rollout size: about 8.0 MB;
canonical latest ordinal: 851 and still growing;
projection next byte offset: 1,908,709;
projection next ordinal: 167;
maximum projected ordinal: 164;
projected items: 55;
projected turns: 2;
SQLite quick check: ok.

After restart, thread/resume returns success but reports only the old interrupted turn and turnCount=2. New turn/start requests also return success with no RPC error, and the engine emits reasoning activity for the new turn, but the Desktop history/UI does not advance. To the user, follow-up messages in this thread appear to do nothing.

This demonstrates a second containment gap: advancing past a verified duplicate boundary is sufficient for one thread but not enough to recover every already-wedged projection. The durable rollout can continue to append hundreds of valid ordinals while the materialized history remains frozen without surfacing an error.

Requested product fix

Provide an automatic full re-projection fallback when a cursor repair does not advance the materialized history.
Detect rollout latest ordinal >> projection ordinal after resume and rebuild instead of returning a successful but stale thread/resume.
Reject or visibly fail turn/start if the new turn cannot become visible through the thread projection.
Add a supported history repair/reindex command and keep one poisoned thread from affecting the shared app-server.

No thread IDs, local paths, prompts, conversation content, credentials, or raw logs are included. Backups and incident bundles are retained locally for private follow-up.

Adding one untouched/read-only data point for the rollout latest ordinal >> projection ordinal case mentioned above.

On another Windows 11 paginated thread using recorded runtime codex-cli 0.149.0-alpha.4.3, I found exactly one non-monotonic boundary in the entire rollout:

20195 event_msg/token_count
20195 event_msg/thread_settings_applied
20196 event_msg/task_started

The persisted projection cursor expected 20196 at exactly the byte offset where the second 20195 began.

The canonical rollout remained valid and continued normally through ordinal 21535, while the history projection remained stuck at that duplicate boundary.

No rollout or SQLite repair has been applied; the original stalled state is still preserved for read-only inspection if maintainers need additional sanitized checkpoint/offset metadata.

Follow-up from a second affected Windows store, plus a tested defensive patch.

Additional evidence

All active SQLite databases passed PRAGMA quick_check, foreign_key_check, and migration checks. This is a logical projection stall, not database corruption.
Four live threads were wedged at the same time, producing more than 1,200 repeated failed to project durable rollout warnings.
Across the 43 rollouts currently represented in thread_history_projection_state, I found 10 non-monotonic ordinal transitions.
The longer duplicate runs show two ordinal streams colliding. One observed sequence was effectively:
- token_count: N, N+1
- thread_settings_applied: N
- thread_goal_updated: N+1
- normal turn history resumes at N+2

The projector currently treats every ordinal < next_ordinal as fatal. That means even stale records which produce no thread-history changes permanently wedge the projection before it reaches valid later turns.

Proposed narrow recovery

I prepared a minimal patch here:

TryDotAtwo@c148c15

It skips a stale ordinal only when all of these are true:

the line decoded successfully;
no rejected lines are pending before it;
project_rollout_line produces neither changed turns nor changed items;
the line is not a projected realtime item.

Meaningful duplicate/out-of-order records still fail closed, so the existing corruption guard remains intact. This is deliberately a projector resilience fix; writer serialization/tail refresh should still be addressed separately to prevent duplicate assignment at the source.

Verification

Added a real regression test with two projection-noop records sharing ordinal 1, followed by a valid turn_started at ordinal 2.
Before the patch it fails with expected ordinal 2, got 1.
After the patch it catches up to EOF and materializes the later turn at ordinal 2.
The existing test that rejects meaningful duplicate ordinals still passes.
Full result: cargo test -p codex-thread-store — 235 passed, 0 failed.

The repository contribution policy does not accept external PRs, so I am attaching the tested implementation here for maintainers to cherry-pick or adapt.

Opened #41353 to track the broader producer-side root cause: competing/stale paginated rollout writers emitting overlapping ordinal sequences across multiple live threads. This issue remains the concrete UI/projection-stall symptom report.

Independent confirmation on Codex Desktop for macOS while accessing a remote Linux project, observed across Codex 0.149.0 and 0.150.1. The canonical paginated rollout remained parseable and contained later valid records, but the displayed task history consistently stopped at the same older boundary. Restarting Codex and upgrading did not rebuild or advance the projection.

Sanitized inspection showed the same structural failure class: a repeated boundary ordinal involving a token_count record and subsequent metadata, followed by an expected N+1, got N projection failure. This appears to connect the desktop symptom here with #35746.

No transcript content, thread/session IDs, project names, paths, timestamps, exact ordinals, credentials, screenshots, or raw logs are being shared. A regression test should be reproducible with entirely synthetic rollout records.

I traced one reproducible source of the duplicate ordinal reported here.

On restart, the recorder scans the end of a paginated rollout to recover the next ordinal. If the final record is a token_count event with nested floating-point rate-limit values, deserializing it directly as RolloutLine can fail when serde_json/arbitrary_precision is enabled.

The scanner skips that valid record, falls back to the preceding one, and then reuses the skipped ordinal. The regression test produces 0, 4, 5, 5 before the fix and 0, 4, 5, 6 afterward.

PR #38399 added decode_rollout_line for this serde compatibility case, but the ordinal tail scanner still used direct deserialization. The reference patch routes that scan through the existing decoder:

just test -p codex-rollout passes all 127 tests, including the new restart regression test.

I’m posting the tested branch here as a reference for an OpenAI-owned fix. This prevents this restart path from creating new duplicates.

Confirming the same side-chat failure on a newer Windows package, with a token_count -> task_started duplicate boundary.

Environment

Windows 25H2 x64, build 26200.9168
Microsoft Store package OpenAI.Codex 26.825.5331.0
Bundled backend codex-cli 0.151.0-alpha.7.1
Paginated local task

Exact failure

Opening a side chat invokes thread/fork and returns -32603:

failed to prepare paginated fork: thread history projection expected ordinal 30264, got 30263

The sanitized duplicate boundary is:

ordinal 30263  event_msg/token_count
ordinal 30263  event_msg/task_started
ordinal 30264  later valid history continues

The persisted projection checkpoint is:

next_rollout_byte_offset = 914767053
next_rollout_ordinal     = 30264

That byte offset points exactly at the second ordinal-30263 record.

Durable history versus projection

The rollout remains newline-valid and continues appending valid records through approximately ordinal 53965.
The projection remains stuck at expected ordinal 30264.
The rollout is unusually large, approximately 1.83 GB with about 44,000 records, but the fork fails quickly with the deterministic ordinal mismatch above, so file size alone does not explain the failure.
SQLite PRAGMA quick_check(1) returns ok.
codex doctor reports the databases as healthy and says rollout/state-DB inventory agrees, so the current doctor checks do not detect this semantic projection stall.
Restarting and updating the Desktop app did not repair it.

The local session index also contains duplicate display entries for the same conversation, with one automatically suffixed (2). This may be related to restart/resume or migration behavior, although the immediate side-chat failure is the duplicate ordinal boundary above.

No thread IDs, account information, project names, absolute paths, prompts, conversation content, credentials, databases, or raw logs are included.

Additional Windows reproduction with repeated Codex Desktop crashes:

Windows 11 x64; Codex Desktop 26.825.6671.0; bundled Codex CLI 0.151.0-alpha.7.1; paginated history.
The same expected ordinal N, got N-1 failure independently occurred across at least four newly created task contexts: 4714/4713, 3496/3495, 2114/2113, and 4630/4629.
The newest task was a clean root with no history_base, so recreating the task did not prevent recurrence.
Across these four contexts, codex_thread_store::local::live_writer emitted at least 1,145 projection warnings.
In the newest occurrence, thread_history_projection_state expected ordinal 4630, but its stored byte offset pointed to ordinal 4629. SQLite PRAGMA integrity_check returned ok, the rollout remained parseable, and continued through at least ordinal 4999.
Advancing the byte offset from the duplicate 4629 record to the start of ordinal 4630 would move it from 35,818,906 to 35,821,878, while keeping next_rollout_ordinal = 4630.
Latest timeline: the Desktop browser process crashed first, the app relaunched, and the projection mismatch began roughly one minute after relaunch. Therefore the mismatch may be created during crash recovery and may then contribute to subsequent instability; causation of the browser crash itself is not yet minidump-proven.

This extends the original report by showing recurrence across clean replacement tasks and correlation with repeated Desktop browser crashes. No thread IDs, prompts, credentials, absolute paths, or raw transcripts are included.

Independent Windows reproduction on a newer Desktop build with the same duplicate-ordinal boundary and a non-recovering projection.

Environment

Windows 11 25H2, build 26200, x64
Codex Desktop 26.901.4073.0
Local task with paginated history

User-visible behavior

A long-running task displayed only part of its chat history even though current work continued successfully. Read-only task history surfaced an older projected turn as the latest turn after a newer canonical turn had completed.

Canonical rollout versus projection

Canonical rollout: 276,007,322 bytes (263.22 MiB), latest ordinal 30,922
History projection cursor: byte 200,437,876, expecting ordinal 22,708
Unprojected durable suffix: 75,569,446 bytes (72.07 MiB), 8,216 valid JSON records
Projection had materialized only 72.6% of the rollout bytes
Materialized turn/item maxima stopped before the cursor, while the durable suffix contained 58 later task_started, 52 task_complete, and four turn_aborted events

The exact boundary was:

ordinal 22707  event_msg / token_count
ordinal 22707  event_msg / thread_settings_applied
ordinal 22708  event_msg / task_started

The structured log database retained 411 task-tagged projection failures with the same message:

thread history projection expected ordinal 22708, got 22707

Those retained failures span almost 23 hours. Every later durable append retried the same rejected boundary, but the projector did not reconcile, skip the verified duplicate metadata record, or rebuild. The unprojected suffix parsed with zero errors and remained ordinal-sequential after the duplicate. The newest turn completed normally in the canonical rollout.

This confirms the exact #41079 mechanism persists in 26.901.4073.0: duplicate ordinal assignment involving token_count and thread_settings_applied, followed by permanent projection lag while the canonical task continues. Aggregate task size may make the impact larger, but it is not the immediate failure mechanism in this case.

Expected behavior

The projector should prevent duplicate ordinal assignment or automatically reconcile/rebuild from the canonical rollout when it encounters this safe duplicate-metadata boundary. A projection failure must not silently hide all later completed turns, and repeated append attempts should not emit the same warning indefinitely without recovery.

Privacy

No task title or ID, local path, prompt or transcript text, username, repository name, raw log, screenshot, request ID, credential, or project data is included. No internal history or projection files are attached.

Additional sanitized Windows reproduction of the duplicate-ordinal / stalled-history-projection failure, posted with the affected user's explicit permission.

In-app feedback/session ID for correlation: 01a04ce5-546e-73a0-bb7a-9b93f142882e

Current symptoms and verified evidence

Reopening/restarting the desktop application did not restore the missing later conversation.
The canonical rollout still contains later user/assistant records and continues to grow, while the indexed history remains behind.
A read-only check on 2026-09-04 at 15:48 UTC still found the projection expecting ordinal 3626, with ordinal 3625 at its stored byte offset.
A complete scan of an earlier preserved snapshot found three duplicate-ordinal boundaries in this one rollout. The observed boundary pattern was event_msg/token_count followed by event_msg/thread_settings_applied with the same top-level ordinal.
The raw snapshot parsed successfully. Online backups of six local SQLite databases passed integrity checks. This is not evidence of physical transcript deletion.

Isolated tests only — not a recommended workaround

The original files were preserved. Tests used separate state directories without credentials or model turns:

Reading an unchanged copy with its existing history projection reproduced the stale history.
A candidate copy with continuous top-level ordinals preserved all other bytes, but thread/read and thread/turns/list against a fresh history database returned empty history rather than rebuilding it. No thread/resume was attempted in this test.
codex migrate-rollouts --thread <id> --json, without --apply, returned already_paginated and processed zero bytes.

The installed executable used for these isolated tests reported codex-cli 0.153.1. This is not a verified version identification of the running desktop application's bundled backend. No candidate was copied into production; no production projection was edited or cleared.

Requested guidance

Could maintainers associate the feedback ID above with this issue and confirm:

whether a supported, non-destructive per-thread projection recovery method exists for already-paginated history with multiple duplicate boundaries;
the applicable desktop/backend version and exact safe procedure, if available;
or a linked fix/release to follow if recovery requires an update?

The cause of duplicate assignment itself is not established by this local check; network, sleep and restart correlations should not be treated as proven causes.

No conversation text, task title, holdings, screenshots, credentials, local paths, raw logs or databases are attached. Only the explicitly authorized feedback ID and sanitized structural findings are shared.

I can confirm this exact failure pattern on Windows with Codex CLI 0.153.1.

I have two independent affected local threads.

Thread A:

Raw transcript turns: 119
Projected turns: 45
Missing projected turns: 74
Projection error:
expected ordinal 24775, got 24774
Raw rollout JSONL remains complete and parseable through several days of later activity.
No malformed JSONL records.
No duplicate raw turn-start records.
SQLite integrity checks pass.

Thread B:

Raw transcript turns: 15
Projected turns: 6
Missing projected turns: 9
Projection error:
expected ordinal 2796, got 2795
Raw rollout remains complete and parseable.

The affected projection state is in thread_history_1.sqlite.

I also performed an isolated recovery rehearsal on copied state only.

Tested:

Native migrate-rollouts inspection
-> both affected threads report already_paginated.
Native read/resume against the copied faulty state
-> ordinal mismatch repeats; history stays truncated.
Remove only the affected derived projection rows, then native read/resume
-> zero turns returned; no rebuild occurred.
Start with a fresh history DB, then native read/resume
-> zero target turns returned; no historical backfill occurred.

Therefore, on 0.153.1, deleting projection rows or replacing thread_history_1.sqlite is not a working recovery path.

No live Codex state was modified.

The canonical rollout transcripts are still intact, so recovery should be possible if Codex exposes a supported replay/rebuild mechanism.

This appears to be the same class of failure described here: a repeated/older ordinal permanently stalls the paginated history projection while the durable rollout continues growing.

If useful, I can provide sanitized:

projection offsets
exact duplicate-record boundary metadata
runtime log samples
reconciliation counts
without sharing prompts, thread IDs, absolute paths, or project contents.

I was able to recover the affected thread successfully and verify the fix in the live Codex Desktop UI.

Environment:

Windows
Codex Desktop
Codex CLI 0.153.1
Paginated local thread history
Raw rollout JSONL remained complete

Root cause confirmed:

The affected rollout contained repeated ordinal metadata records with this pattern:

token_count N
thread_settings_applied N
task_started N+1

In my larger affected thread there were exactly two such anomalies.

The projector stopped at the first one with:

expected ordinal 24775, got 24774

After bypassing that boundary in an isolated test, it later stopped again with:

expected ordinal 29058, got 29057

A full scan of the 47,766-record rollout found exactly two ordinal anomalies:

two repeated ordinals
zero decreasing ordinals
zero gaps
zero malformed JSON

Both duplicate records were thread_settings_applied.

Recovery method that worked:

Fully stop Codex Desktop and all codex/app-server writers.
Take a coherent backup of the full Codex home/state.
On an isolated copy first, stream-rewrite the rollout JSONL.
Remove ONLY the two verified redundant thread_settings_applied records.
Do NOT renumber ordinals.
Do NOT edit thread history rows manually.
Do NOT modify next_rollout_ordinal.
Preserve every other rollout record byte-for-byte.
Start the version-matched native app-server and allow the existing projector to resume.

Important detail:

The first duplicate record was located exactly at the existing
next_rollout_byte_offset.

After removing that duplicate, the next valid task_started record with the
expected ordinal occupied the same logical cursor position.

Therefore no history DB cursor edit was required.

Isolated recovery result:

Before:

Raw turns: 119
Projected turns: 45
Missing turns: 74
Projected items: 8,408

After:

Projected turns: 119 / 119
Projected items: 16,087 / 16,087
User messages: 117 / 117
Assistant messages: 865 / 865
Missing: 0
Duplicate: 0
Unexpected: 0
Ordering errors: 0
Relationship errors: 0
Content mismatches: 0

The native paginated API returned the complete history and the repaired
projection survived restart.

I then performed the same procedure against the live thread using:

all Codex writers stopped
full coherent backup
exact transcript hash/baseline gates
streamed temporary replacement rather than in-place editing
native projector only
automatic rollback on validation failure

Live result:

119 turns / 16,087 items restored successfully.

After reopening Codex Desktop, the previously missing history was visible again.
A subsequent restart preserved the restored history.

One smaller thread with a single duplicate ordinal was also repaired in
isolation by advancing only the byte offset past the redundant metadata record.

Important warning:

I would NOT recommend blindly deleting projection rows or replacing
thread_history_1.sqlite.

On Codex 0.153.1, both of those approaches failed to rebuild history and could
leave the thread with zero projected turns.

I also would not recommend blindly editing next_rollout_ordinal.

The recovery worked because the duplicate metadata records were first identified
and verified directly in the canonical rollout JSONL.

A supported Codex repair command would still be preferable.

Ideally the projector could detect this pattern:

ordinal N
redundant metadata ordinal N
next valid ordinal N+1

and safely skip/reconcile the redundant metadata record rather than permanently
stalling the paginated history projection.

Additional Windows reproduction with a complete durable rollout but a severely stale paginated history projection.

Environment:

Codex desktop 26.901.5280.0
bundled CLI 0.153.4
Windows 11

Observed durable data:

rollout size: 350,050,667 bytes
37,962 valid JSONL records
final ordinal: 37,959
final assistant response and task-complete records are present
two duplicate ordinal boundaries only
both duplicates have the exact sequence event_msg/token_count followed by event_msg/task_started with the same ordinal; the following record is ordinal + 1

Observed derived state:

projection cursor: byte 68,484,479, next ordinal 9,078
projection lag: 281,566,188 bytes
only 2,641 items / 12 turns materialized
audit of 1,343 projection rows found this as the only lagging projection
SQLite PRAGMA integrity_check passes
codex doctor --json reports both state/history DB integrity and rollout parity as healthy, so it does not detect this failure

The log previously showed the projector reaching the second boundary (expected ordinal 9457, got 9456). After a later desktop update/restart, the projection cursor regressed to the first boundary, even though the rollout remained unchanged. This makes a DB-cursor-only workaround non-durable across projection rebuilds.

An isolated recovery test confirms the causal pattern: removing only the two duplicate token_count telemetry records (retaining both task_started records and every content record) makes the ordinal stream contiguous, after which Codex's own app-server projects to exact EOF / next ordinal 37,960 and the history database remains integrity-clean.

Suggested fixes:

Writer: allocate a fresh ordinal for task_started after interruption/resume instead of reusing the preceding token_count ordinal.
Materializer: tolerate or deterministically deduplicate this exact non-content duplicate pattern without aborting the transaction.
Doctor: compare each projection cursor's byte offset and next ordinal with the actual rollout EOF/final ordinal, and report lag/regression even when both SQLite databases pass integrity checks.

No transcript content is included here, but I can provide a small synthetic JSONL reproducer if useful.

Follow-up from the same Windows reproduction:

The backup-first normalization/replay completed successfully and a global audit then showed 1,344 projection rows matching 1,344 durable rollouts, with zero missing, lagging, or malformed rollouts.
Restarting Codex made the previously missing messages visible.
A later read-only audit nevertheless detected the same task drifting again: projected_offset == rollout_size (zero bytes behind), while next_ordinal was already two behind the ordinal implied by the complete rollout.
The durable transcript remains intact. The only anomaly is again the previously reported pair of duplicate telemetry boundaries.

This suggests the UI can temporarily look recovered while the derived projection is already internally inconsistent again. Comparing only cursor byte offset to EOF is therefore insufficient; doctor/materializer validation should also compare next_ordinal with the durable record sequence and tolerate or normalize this exact non-content duplicate pattern.

I have installed a local backup-first, fail-closed audit/repair button as a temporary workaround, but an in-product Rebuild task history index action would be much safer and more discoverable for affected users.

Additional Windows case, diagnosed and recovered on 2026-09-05, with the affected user's explicit permission to submit this technical report. This adds evidence from desktop package 26.901.5280.0 and, importantly, user-confirmed recovery in the desktop UI.

Environment and scope

Windows x64; desktop package OpenAI.Codex 26.901.5280.0 (ChatGPT.exe).
Running app-server executable verified as codex-cli 0.153.4 during diagnosis.
The affected conversation records runtime version 0.153.1. This is not a claim that 0.153.4 originally wrote the duplicate.
Local conversation with paginated history.
The user reports this symptom around updates. An earlier local intervention also documented a duplicate settings ordinal in another conversation, but the causal role of updates has not been established.

Verified failure

The saved rollout contained later work and its final assistant response / task_complete, while the application returned an earlier turn as interrupted and omitted the later completed turn.

Observation	Value
Canonical rollout size	98,681,704 bytes
Stalled projection byte offset	98,299,689
Expected next ordinal	2329
Pending suffix before correction	382,015 bytes
Matching retained projection warnings	108

The exact boundary was:

offset 98298870..98299689: ordinal 2328, event_msg / token_count
offset 98299689..98301720: ordinal 2328, event_msg / thread_settings_applied
offset 98301720..98301968: ordinal 2329, event_msg / task_started

A full scan found exactly one ordinal discontinuity: the settings event above repeated the preceding ordinal. Subsequent records continued consecutively through ordinal 2451, including the final response and completion.

Warnings from codex_thread_store::local::live_writer occurred between 2026-09-05 01:34:43 and 01:47:47 UTC and ended with:

failed to project durable rollout for <redacted-thread-id>:
thread-store internal error: thread history projection for
<redacted-thread-id> expected ordinal 2329, got 2328

The state and history databases passed PRAGMA quick_check.

Recovery performed and verified

This is an account of a guarded local workaround, not general advice to edit SQLite or a supported product fix.

Created SQLite online backups of the state, history and application catalog databases, plus copies of the affected rollout and app state. Verified backup integrity and hashes.
Checked that the target rollout and projection cursor had not changed.
Changed exactly one projection-state row: advanced only next_rollout_byte_offset from 98299689 to 98301720, keeping next_rollout_ordinal=2329. This bypassed the 2,031-byte duplicate settings event for projection only.
Archived and immediately unarchived the idle conversation through application tools to refresh its reading. The desktop application was not restarted, and the final state is unarchived.
The native projection caught up to exact EOF: byte offset 98681704, next ordinal 2452, consistent with final durable ordinal 2451.
The application returned the previously omitted latest turn as completed, with 44 items and the final response. The user reopened the conversation and explicitly confirmed that the final response was visible again.
The canonical rollout SHA-256 remained identical to the pre-repair backup. No canonical record was deleted, renumbered or rewritten. State, history and application catalog integrity checks remained clean.

A broader local inventory found 262 rollout files matching 262 registered sessions, no unregistered rollout files, and no other projection cursor behind EOF at the checked snapshot (excluding the actively writing diagnostic conversation). This is not a claim that every page of every conversation, or cloud history, was visually validated.

Remaining issue / requested maintainer guidance

The original duplicate record is preserved, so a future full projection rebuild could encounter the same boundary again. A successful local recovery is not a permanent fix.

Could maintainers confirm:

Which desktop/app-server release prevents this duplicate ordinal assignment or safely reconciles it?
Whether that release recovers already-stalled paginated histories, rather than only preventing new incidents?
The supported per-conversation recovery procedure, with backup and validation, if one exists?
Whether the app can surface a clear history-projection error instead of silently presenting an older conversation?

No conversation title or ID, prompts, transcript content, personal filesystem paths, credentials, raw logs, screenshots or database attachments are included. No in-app feedback upload is being claimed.

Thank you for sharing these findings. We have now recovered our affected thread’s backend history index: 289 turns are indexed, compared with 63 before recovery. Our transcript contained three duplicate metadata boundaries. After backups and isolated testing, we rebuilt the derived history using the native component and mapped its byte offsets back to the unchanged original transcript. Database integrity checks pass, and subsequent messages continue to update correctly. The user has confirmed that the missing conversations are visible again in the desktop app. A desktop restart test is still pending. The original duplicate metadata remains preserved, so we do not consider this a permanent fix. Could maintainers confirm which release prevents this issue and provides supported recovery for already-affected conversations? ThalamicBarrel ***@***.***> 于2026年9月6日周日 02:50写道：

…

*ThalamicBarrel* left a comment (openai/codex#41079) <#41079 (comment)> Additional Windows case, diagnosed and recovered on 2026-09-05, with the affected user's explicit permission to submit this technical report. This adds evidence from desktop package 26.901.5280.0 and, importantly, user-confirmed recovery in the desktop UI. Environment and scope - Windows x64; desktop package OpenAI.Codex 26.901.5280.0 (ChatGPT.exe ). - Running app-server executable verified as codex-cli 0.153.4 during diagnosis. - The affected conversation records runtime version 0.153.1. This is not a claim that 0.153.4 originally wrote the duplicate. - Local conversation with paginated history. - The user reports this symptom around updates. An earlier local intervention also documented a duplicate settings ordinal in another conversation, but the causal role of updates has not been established. Verified failure The saved rollout contained later work and its final assistant response / task_complete, while the application returned an earlier turn as interrupted and omitted the later completed turn. Observation Value Canonical rollout size 98,681,704 bytes Stalled projection byte offset 98,299,689 Expected next ordinal 2329 Pending suffix before correction 382,015 bytes Matching retained projection warnings 108 The exact boundary was: offset 98298870..98299689: ordinal 2328, event_msg / token_count offset 98299689..98301720: ordinal 2328, event_msg / thread_settings_applied offset 98301720..98301968: ordinal 2329, event_msg / task_started A full scan found exactly one ordinal discontinuity: the settings event above repeated the preceding ordinal. Subsequent records continued consecutively through ordinal 2451, including the final response and completion. Warnings from codex_thread_store::local::live_writer occurred between 2026-09-05 01:34:43 and 01:47:47 UTC and ended with: failed to project durable rollout for <redacted-thread-id>: thread-store internal error: thread history projection for <redacted-thread-id> expected ordinal 2329, got 2328 The state and history databases passed PRAGMA quick_check. Recovery performed and verified This is an account of a guarded local workaround, not general advice to edit SQLite or a supported product fix. 1. Created SQLite online backups of the state, history and application catalog databases, plus copies of the affected rollout and app state. Verified backup integrity and hashes. 2. Checked that the target rollout and projection cursor had not changed. 3. Changed exactly one projection-state row: advanced only next_rollout_byte_offset from 98299689 to 98301720, keeping next_rollout_ordinal=2329. This bypassed the 2,031-byte duplicate settings event for projection only. 4. Archived and immediately unarchived the idle conversation through application tools to refresh its reading. The desktop application was not restarted, and the final state is unarchived. 5. The native projection caught up to exact EOF: byte offset 98681704, next ordinal 2452, consistent with final durable ordinal 2451. 6. The application returned the previously omitted latest turn as completed, with 44 items and the final response. The user reopened the conversation and explicitly confirmed that the final response was visible again. 7. The canonical rollout SHA-256 remained identical to the pre-repair backup. No canonical record was deleted, renumbered or rewritten. State, history and application catalog integrity checks remained clean. A broader local inventory found 262 rollout files matching 262 registered sessions, no unregistered rollout files, and no other projection cursor behind EOF at the checked snapshot (excluding the actively writing diagnostic conversation). This is not a claim that every page of every conversation, or cloud history, was visually validated. Remaining issue / requested maintainer guidance The original duplicate record is preserved, so a future full projection rebuild could encounter the same boundary again. A successful local recovery is not a permanent fix. Could maintainers confirm: - Which desktop/app-server release prevents this duplicate ordinal assignment or safely reconciles it? - Whether that release recovers already-stalled paginated histories, rather than only preventing new incidents? - The supported per-conversation recovery procedure, with backup and validation, if one exists? - Whether the app can surface a clear history-projection error instead of silently presenting an older conversation? No conversation title or ID, prompts, transcript content, personal filesystem paths, credentials, raw logs, screenshots or database attachments are included. No in-app feedback upload is being claimed. — Reply to this email directly, view it on GitHub <#41079?email_source=notifications&email_token=CMW5FTEKTAKH5JMRFHQCOBT5NROA7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJVGQYDENRXHE3KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5554026796>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CMW5FTCO5CBOAVG2GAGLMOD5NROA7AVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TKMRWGQ4TSNRSG42KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CMW5FTBQTR63MEK6NCTE2TD5NROA7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJVGQYDENRXHE3KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/CMW5FTAQENEM7FETTO3VFGT5NROA7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJVGQYDENRXHE3KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

Also observed on Linux x86_64 with Codex CLI 0.153.4. Resuming a paginated conversation omits recent messages, while the original JSONL transcript contains them. Logs repeatedly report thread history projection for <redacted-thread-id> expected ordinal 815, got 814. The projection remains behind the saved transcript. This suggests the issue is not limited to Windows. No database edits or repair attempts were made.

Additional macOS reproduction: projection checkpoint matches one duplicate metadata ordinal

Observed on 2026-09-07. This matches the failure signature in this issue, so I am adding a sanitized reproduction instead of opening a duplicate.

Environment

Desktop app: 26.901.51231, build 8109, bundle identifier com.openai.codex.
macOS 26.5.1, Apple Silicon / arm64.
Installed bundled CLI: codex-cli 0.153.4.
Affected rollout's recorded writer version: 0.153.0-alpha.5.
History mode: paginated.

User-visible symptom

A long local task now appears to contain only its first two turns. Later discussions and completed work are still present in its original rollout. Re-reading via the desktop task-reading tool returns those same two turns with nextCursor: null and hasMore: false. The second turn is exposed as interrupted; its stored projection row is still inProgress. Desktop logs show successful thread/read, thread/turns/list, and thread/items/list responses, so callers receive an apparently successful but incomplete history.

Read-only evidence

Canonical JSONL: 4,746 records, 67,290,636 bytes; every line parses as JSON.
It contains 88 task_started and 86 task_complete events.
Exactly one non-contiguous ordinal transition was found in the entire file.
thread_history_projection_state remains at:
- next_rollout_byte_offset = 2833133
- next_rollout_ordinal = 286
The history database contains only two projected turn rows for this task.
PRAGMA quick_check returns ok for both state_5.sqlite and thread_history_1.sqlite.

Boundary, with all payload contents omitted:

JSONL line (1-based)	Byte offset	Ordinal	Record type
286	2832321	285	`event_msg/token_count`
287	2833133	285	`event_msg/thread_settings_applied`
288	2835114	286	`event_msg/task_started`
289	2835361	287	`turn_context`

The stored byte checkpoint points exactly to the second ordinal-285 record. Later records continue through ordinal 4744.

The local runtime log contains repeated warnings from codex_thread_store::local::live_writer:

thread history projection for <redacted-thread-id> expected ordinal 286, got 285

Source comparison and recovery question

Both the writer-version source and the installed-version source return an error when ordinal < next_ordinal, matching this checkpoint and log error.

I also found the merged fixes:

Keep SQLite history projection moving past invalid records #42369 — keep projection moving past invalid/discontinuous records.
Route rollout reads through the canonical JSON decoder #42378 — use canonical JSON decoding, including reverse scanning on resume.

The checked rust-v0.153.4 projection code still has the strict rejection above, whereas current main includes the new duplicate/regressed-ordinal handling. Which released desktop/runtime build contains these changes, and should opening an already-wedged task in that build automatically advance its existing projection checkpoint?

The duplicate boundary and resulting projection stall are directly observed. The original cause of duplicate assignment is not proven here: competing/stale writer state is one possibility; the tail-decoder/resume issue addressed in #42378 is another lead. This report does not claim a deterministic reproduction of the producer race.

No repair, cursor advance, rollout rewrite, or database edit has been performed. No transcript contents, task identifiers, credentials, account details, or private project paths are included.

Additional Windows reproduction: mobile-visible truncation with exact duplicate ordinal boundary

Adding another independently verified case to this issue rather than opening a duplicate.

Environment

Windows x64
Installed Microsoft Store package: OpenAI.Codex 26.901.6511.0
Desktop log release active during the observed projection failures: 26.901.51231
Affected rollout recorded writer version: codex-cli 0.153.0-alpha.5
Local thread with paginated history
Mobile client: ChatGPT mobile Remote (OS/app build not captured)

User-visible symptom

Opening this long-running Codex thread on mobile shows only a small portion of the conversation and makes much of the prior context unreachable. The local host transcript still contains the missing work. A desktop/API history read likewise exposes only two projected turns, even though the canonical rollout contains 14 task_started and 12 task_complete events.

The user associates the visible truncation with opening the thread on mobile. This report does not claim that mobile access created the durable defect; it may only expose an already-stalled projection.

Read-only structural evidence

Canonical rollout: 8.21 MiB, 1,457 JSONL records
All 1,457 lines parse successfully; zero malformed JSON records
Explicit ordinal range: 0 through 1455
Exactly one duplicated ordinal and no other ordinal discontinuity
The rollout also contains two large compaction records; the largest JSONL record is 1,035,999 characters. This may amplify loading cost, but the ordinal defect below is independently confirmed by application errors.

Exact boundary, with payload contents omitted:

UTC timestamp	JSONL line	Ordinal	Record type
`2026-09-08T01:03:00.404Z`	922	921	`event_msg / token_count`
`2026-09-08T01:03:23.877Z`	923	921	`event_msg / thread_settings_applied`
`2026-09-08T01:03:23.888Z`	924	922	`event_msg / task_started`

The two ordinal-921 records contain different metadata and should both be preserved.

Corroborating desktop logs

Five thread/fork attempts failed with JSON-RPC -32603 and the same internal error:

failed to prepare paginated fork: thread-store internal error:
thread history projection for <redacted-thread-id> expected ordinal 922, got 921

The paired composer logs report side chat failed with the same message. Earlier retained desktop logs also contain three Conversation state not found errors for this conversation, though their relationship to the duplicate ordinal is not established.

Expected behavior

A settings/resume boundary must allocate the next ordinal atomically rather than reusing the preceding token_count ordinal.
An already-affected projection should self-heal or offer a supported, non-destructive repair path while preserving both distinct metadata records.
Mobile and desktop should not silently present a partial transcript as the complete conversation; the UI should surface an actionable projection error if history hydration is incomplete.

No rollout, database, projection cursor, or application state was modified during this investigation. No task identifiers, absolute paths, prompts, source code, credentials, or raw logs are included.

Additional recurrence report from another Windows installation: this has affected several separate paginated conversations, not just one transcript.

Environment observed on 2026-09-09:

Windows, Codex Desktop package 26.901.6511.0
Installed standalone CLI: 0.153.4 (this does not establish which writer version originally created each duplicate)

Latest affected conversation, inspected read-only:

Canonical JSONL: 807,156,838 bytes, zero JSON parse errors.
264 unique turn IDs in the union of turn_context and task_started events; only 248 in thread_turns (16 missing, zero extra).
Projection cursor: next_rollout_byte_offset=792189762, next_rollout_ordinal=38253.
Exactly one repeated ordinal, with this sequence:
- bytes 792188857..792189762: ordinal 38252, event_msg/token_count
- bytes 792189762..792191807: ordinal 38252, event_msg/thread_settings_applied
- bytes 792191807..792192056: ordinal 38253, event_msg/task_started
The durable tail reaches ordinal 40186, but the app history reader returns the older projected history.
No repair has been applied to this latest conversation.

Two earlier independent cases on the same installation were tested in isolated database/rollout copies:

Single duplicate 1271 (token_count, then thread_settings_applied): advancing only the projection byte cursor from 5472419 to 5475819, retaining expected ordinal 1272, followed by thread/resume recovered all 43 turns / 523 items and reached EOF (7595448, 1815). SQLite quick_check passed and the JSONL SHA-256 stayed unchanged. This was verified with CLI 0.153.4.
Repeated block 4168,4169,4168,4169,4170: the original pair was token_count/token_count; the repeated pair was thread_settings_applied/task_started. Isolated cursor reconciliation and thread/resume reached EOF and recovered 208 turns / 8728 items, with matching raw/projected turn IDs, quick_check=ok, and unchanged JSONL hash. This was verified with CLI 0.150.1. This is evidence of a two-ordinal variant, not a recommendation to blindly skip task_started records.

These isolated tests are recovery evidence, not claims of a supported repair or of a permanent fix. Simply reading paginated history did not advance the stalled projection in the tests; opening/resuming the isolated conversation did after cursor reconciliation. The writer-side trigger remains unproven; the repeated records occur at settings/resume boundaries.

User impact: later inputs and outputs appear to disappear when reopening conversations, while the durable records remain on disk. Per-conversation recovery does not prevent another conversation encountering the same failure. Please investigate both ordinal assignment and automatic projection recovery, and provide an actionable UI error or supported doctor command.

No conversation content, task IDs, project names, local paths, raw logs, credentials, or database files are included.

Hi all, I think many of these bugs are structural consequences of Codex's thread-state design, where backend state, frontend state, resume/reopen, pagination, updates, cross-device/Remote Control, and compaction all maintain or reconstruct the same conversation through separate pathways, so if you have isolated a specific trigger or root cause, I recommand you to open a new separate issue

Additional Windows reproduction: duplicate ordinal 23 blocks projection at byte 193367

Adding verified boundary evidence from another installation on package 26.901.6511.0. The token_count / thread_settings_applied pair matches the ordering pattern described in this issue. No repair was attempted in this case.

Summary

An existing Codex Desktop conversation ("Thread B") has two consecutive valid JSON records with ordinal: 23 in its durable rollout. The history projector stops exactly at the second record, repeatedly reporting expected ordinal 24, got 23. The derived history remains incomplete and shows stale inProgress metadata while the runtime is idle.

The source ordering defect and its relationship to the projection failure are directly verified. The component, version, and event that originally wrote the duplicate have not been identified.

Version / environment

Windows 11 Pro, 10.0.26200.9445, x64.
Installed package: OpenAI.Codex_26.901.6511.0_x64__2p2nqsd0c76g0.
Desktop client version reported in logs: 26.901.51231 (a separate version field).
Desktop uses Electron/Chromium and a local app-server over stdio.
Investigation: September 9, 2026. All timestamps below are UTC.

These are the versions present during diagnosis; they do not establish which version created the historical duplicate on September 5.

Observed evidence

At 2026-09-09T19:28:06.206845Z, the durable rollout was 57,494,219 bytes, while the projection checkpoint was:

next_rollout_byte_offset = 193367
next_rollout_ordinal = 24

The records at this boundary were:

Line (1-based)	Start byte	End byte	Length	Ordinal	Event	Timestamp (UTC)
24	192567	193367	800	23	`token_count`	2026-09-05 20:21:09.839
25	193367	196922	3555	23	`thread_settings_applied`	2026-09-05 20:29:47.743
26	196922	197168	246	24	`task_started`	2026-09-05 20:29:47.764

The first 26 records were valid, newline-terminated JSON. The next source record at the checkpoint therefore contains 23 when the projector correctly expects 24. Repeated projection warnings were observed on September 9 around 19:12-19:14 UTC. Only five projected items and stale inProgress metadata dating from September 5 remained in the derived history.

A complete envelope/ordinal audit at 2026-09-09T19:32:55.460486Z, bounded by the initial file size, read all 3,121 records / 57,494,219 bytes. All records parsed successfully and had ordinals. Exactly one adjacent duplicate and one globally repeated ordinal were found; there were no forward gaps or regressions. Ordinals ran from 0 through 3119, with that one repetition.

Repeated warnings therefore demonstrate retries at one historical defect, not repeated creation of new duplicate records.

Reproduction / limits

This is an observed persisted defect, not a deterministic clean-install reproduction. The 8-minute-38-second gap before thread_settings_applied suggests investigating resume/append ordering, but does not prove a particular trigger or writer. Inspection was read-only; no history, checkpoints, settings, or caches were modified, and no repair has been validated.

A separate existing-thread open/send stall before thread/resume occurred in another conversation with a fully current projection and 762 valid records, ordinals 0-761, with no anomalies. This duplicate must not be treated as the demonstrated cause of that separate symptom.

Expected behavior

Durable source ordinals should remain unique and sequential across append/resume. A malformed sequence should produce an actionable recovery path rather than indefinitely stale derived history.

Proposed investigation

Please investigate ordinal allocation/persistence around resume and the transition to thread_settings_applied / task_started, plus supported recovery of this conversation's projection while preserving its durable history. A regression test using a synthetic duplicate-ordinal boundary may help verify detection and recovery. Raw conversations, screenshots, identifiers, and source-bundle excerpts are omitted from this public report.

Additional Windows case on package 26.903.9818.0: duplicate ordinal 6195 at the stalled checkpoint

Adding sanitized evidence from a local desktop task inspected on September 11, 2026. The boundary matches the token_count → thread_settings_applied pattern in this issue.

Environment

Windows x64; PowerShell reports Microsoft Windows NT 10.0.26200.0.
Installed Microsoft Store package: OpenAI.Codex 26.903.9818.0, verified with Get-AppxPackage. This is the package version at diagnosis, not proof of the writer version that created the duplicate.

Observed symptom
The user reports that recent chat history appears to be missing. The app-provided read_thread tool, called newest-first without a cursor, returns September 9 turns even though the original rollout contains later user/assistant messages through September 11. The UI complaint was user-reported; the stale history-tool result and local metadata were independently checked.

Read-only evidence
Snapshot at 2026-09-11T05:16:31Z:

Original rollout: 77,274,543 bytes / 7,414 JSONL records, with zero JSON parsing failures. This establishes syntax validity, not semantic compatibility or completeness of all historical messages.
thread_history_projection_state: next_rollout_byte_offset = 53943684, next_rollout_ordinal = 6196.
The newest projected turn remains inProgress, with no completion timestamp, dating from September 9.
Later user/assistant messages were located in the original file and locally extracted for continuity.

A subsequent targeted, read-only check confirmed this exact unchanged boundary:

JSONL line (1-based)	Byte offset	Ordinal	Record
6196	53942875	6195	`event_msg / token_count`
6197	53943684	6195	`event_msg / thread_settings_applied`
6198	53945679	6196	`event_msg / task_started`
6199	53945927	6197	`response_item / message`

The stored checkpoint expects 6196 but points to the second 6195 record. The two records have different event types; this is a duplicate ordinal, not a claim that the payloads are identical. Boundary timestamps are 2026-09-09T10:06:41.207Z and 2026-09-09T10:09:59.228Z.

Limits and requested recovery
The producer trigger and failing runtime code path remain unconfirmed; no corresponding projection-error log was established in this investigation. Multiple compactions exist in the transcript, but compaction has not been established as the cause.

No source rollout, history database, or projection cursor was edited. No cache reset, forced reindex, or app restart was tested as a repair. A new task plus a local handoff summary restored workflow continuity; it did not repair the old task's history.

Please provide a supported recovery path for already-affected tasks and an actionable warning when history projection is stale. No conversation text, project details, account identifiers, task IDs, credentials, raw logs, or private paths are included in this public comment.

[Desktop][Windows] Paginated thread history stalls on duplicate ordinal while rollout remains complete #41079

Description

Summary

Environment

Sanitized evidence

Expected behavior

Likely cause

Requested fixes

Privacy

Activity

github-actions commented on Aug 27, 2026

wangistiger-beep commented on Aug 27, 2026

Sanitized samples

Durable data versus visible history

Requested investigation

vars0 commented on Aug 28, 2026

Environment

Sanitized sequence

Requested containment

vars0 commented on Aug 28, 2026

Actions performed locally

Outcome

Requested product fix

zshs000 commented on Aug 28, 2026

TryDotAtwo commented on Aug 28, 2026

Additional evidence

Proposed narrow recovery

Verification

TryDotAtwo commented on Aug 28, 2026

Gavin-Qiao commented on Aug 28, 2026

cis-aconiticacid commented on Aug 28, 2026

XingChen15 commented on Aug 29, 2026

Environment

Exact failure

Durable history versus projection

abangkis commented on Aug 30, 2026

8 remaining items

scraptechindustries commented on Sep 4, 2026

Environment

User-visible behavior

Canonical rollout versus projection

Expected behavior

Privacy

wcs891016-creator commented on Sep 4, 2026

Current symptoms and verified evidence

Isolated tests only — not a recommended workaround

Requested guidance

mjmotamedi commented on Sep 4, 2026

mjmotamedi commented on Sep 4, 2026

matthudson commented on Sep 5, 2026

matthudson commented on Sep 5, 2026

ThalamicBarrel commented on Sep 5, 2026

Environment and scope

Verified failure

Recovery performed and verified

Remaining issue / requested maintainer guidance

wcs891016-creator commented on Sep 5, 2026

Justkant commented on Sep 6, 2026

huashengyou92 commented on Sep 7, 2026

Additional macOS reproduction: projection checkpoint matches one duplicate metadata ordinal

jokrasno commented on Sep 8, 2026

Additional Windows reproduction: mobile-visible truncation with exact duplicate ordinal boundary

Environment

User-visible symptom

Read-only structural evidence

Corroborating desktop logs

Expected behavior

XiaoYangyangs commented on Sep 9, 2026

cis-aconiticacid commented on Sep 9, 2026

ibrahimo-ops commented on Sep 9, 2026

Additional Windows reproduction: duplicate ordinal 23 blocks projection at byte 193367

Summary

Version / environment

Observed evidence

Reproduction / limits

Expected behavior

Proposed investigation

y1399789250-hue commented on Sep 11, 2026

Additional Windows case on package 26.903.9818.0: duplicate ordinal 6195 at the stalled checkpoint

Metadata