[Windows Desktop 26.903.8094 / 0.153.4] Recent history unreadable after restart while canonical transcript advances

Summary

On Windows Codex Desktop, a long-running local task shows old conversation history after an application restart, while its canonical local JSONL transcript continues to contain recent public assistant messages and completed work.

The app-provided history reader also returns the old history. This is not just a screenshot/rendering complaint: the newest-first history response and the durable transcript disagree. The exact projector/parser cause has not yet been established.

Environment

• Windows 11 Pro x64, OS version 10.0.26200.
• Installed Microsoft Store package: OpenAI.Codex 26.903.8094.0 (read from package metadata, not the About dialog).
• Installed bundled Codex executable reports codex-cli 0.153.4. This does not establish the writer version of every older transcript record.
• Local desktop task, with paginated history.
• Observed September 8–9, 2026; timestamps below are UTC.
• The user-profile .codex directory is a Windows junction to another local drive. Both paths resolve to the same transcript, not separate copies.

Observed sequence and read-only evidence

This is an observed recurrence, not a deterministic clean-install reproduction:

1. Continue a local development task over multiple days, including compaction and completed work.
2. After restarting the desktop application, the user sees an older subtask and cannot see substantial recent conversation history.
3. Repeated calls to the app-provided read_thread tool, without a cursor and with newest-first ordering, return a newest turn beginning 2026-09-05T09:51:20Z, still marked inProgress. Task metadata remains active and has a September 9 update time.
4. The last returned item maps to an actual canonical transcript entry at 2026-09-05T10:05:42.145Z. Valid later entries and later task starts exist after it.
5. The history response has hasMore: true, but following the returned cursor retrieves still older September 5 turns, rather than recovering the missing newer portion.
6. A read-only check of the canonical transcript at approximately 2026-09-09T04:36Z found a file of 600,054,354 bytes. Its last 12 MiB covered 03:31:12.741Z–04:36:09.728Z and parsed without JSON errors after skipping the initial partial line.
7. A separate streaming scan found 342 public assistant message records, including 21 final-response records, between 2026-09-08T07:00Z and 2026-09-09T04:35Z. These are record counts, not a claim that every user message or every conversation turn is complete.
8. Recent verification artifacts still exist and retain their previously verified SHA-256 values. The latest task output continues the current stage rather than the old subtask shown by the history reader.

These observations establish that substantial recent durable content is present but inaccessible through the checked history path. They do not establish that every expected record is intact, that all affected tasks share the same cause, or that the UI has been repaired.

Related execution-continuity concern

After a recorded compaction at 2026-09-09T04:02:37Z, the task's next public response at 04:03:03Z briefly returned to an obsolete subtask. A supervisory correction restored the current work, as confirmed by subsequent public output and artifacts.

The causal relationship between this task drift and the stale history projection is not established. Please investigate whether they share a restoration boundary, rather than treating that relationship as proven. No private prompts or conversation contents are attached.

Expected behavior

• Reopening a task should expose the latest persisted turns, with working pagination.
• If history loading/materialization is incomplete, the UI and task-reading API should report an actionable incomplete-history state rather than silently returning an old snapshot.
• Provide a supported, non-destructive per-task integrity/recovery procedure that preserves canonical records and current work.
• Please clarify the desktop/runtime version containing applicable recovery fixes, and whether already-affected tasks recover automatically.
• Current execution should retain the latest authorized work checkpoint across compaction and restart, or explicitly surface uncertainty.

Related reports and limits

Possibly related: #41079, #43742, and #44048. Please consolidate if appropriate.

Those reports include duplicate-ordinal and projection-checkpoint findings. This installation has not yet been independently verified to have that exact ordinal defect, so this report does not claim the same root cause or recommend copying a database-cursor workaround.

No cache deletion, transcript rewrite, projection-cursor edit, database repair, downgrade, or diagnostic restart was performed during these checks. The reported restart was part of the user's preceding experience.

Privacy

No raw transcripts, database files, task IDs, project names, absolute private paths, source code, credentials, account details, case data, or unredacted logs are attached. This report contains only sanitized observations and aggregate metadata.

Start with the app-provided read_thread path, its newest-first pagination, and the canonical local JSONL transcript described in the report. Investigate the history projector/parser, materialization state, and restoration or compaction checkpoints without modifying stored data. Done means identifying the cause, preserving the latest persisted turns across restart, and exposing an actionable incomplete-history or recovery state when loading cannot complete.