Repository navigation
[Windows Desktop 26.903.8094 / 0.153.4] Recent history unreadable after restart while canonical transcript advances #44054
Description
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
.codexdirectory 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:
- Continue a local development task over multiple days, including compaction and completed work.
- After restarting the desktop application, the user sees an older subtask and cannot see substantial recent conversation history.
- Repeated calls to the app-provided
read_threadtool, without a cursor and with newest-first ordering, return a newest turn beginning 2026-09-05T09:51:20Z, still markedinProgress. Task metadata remains active and has a September 9 update time. - 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.
- The history response has
hasMore: true, but following the returned cursor retrieves still older September 5 turns, rather than recovering the missing newer portion. - 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.
- 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.
- 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.
Activity
github-actions commentedon Sep 9, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
er260 commentedon Sep 9, 2026
also side chat does not work as well
BooM80 commentedon Sep 11, 2026
I can reproduce the same issue on a newer Windows desktop build.
Environment
26.903.9818.00.153.4Observed behavior
This appears to be a history reconstruction/rendering problem, not deletion of the canonical transcript.
Compaction timing
The session contains a compaction record at
2026-09-11T07:49:50Z, but the missing history had already been observed immediately after reopening the window, before that record was written. In this occurrence, compaction cannot be assumed to have triggered the initial disappearance.Expected behavior
Reopening a local task should display the complete user-visible conversation in chronological order, including intermediate turns.
Impact
The UI makes completed work and decisions appear permanently lost even though the canonical transcript remains on disk.
No raw conversation content, private paths, task/session identifiers, account details, or generated files are included or attached. Private diagnostic data can be provided through a secure support channel if needed.
woshishinidie commentedon Sep 12, 2026
Important recurrence: visible history disappeared while the app remained open (no exit or restart)
Please investigate this as a high-impact conversation-continuity problem, not only a restart/reopen problem.
On September 12, 2026 (UTC), the user reported another substantial gap in the visible conversation and explicitly confirmed that they had not exited or restarted the application during this occurrence. Previously discussed requirements had already been sent to another active task and acknowledged there, but the corresponding discussion was no longer visible in the originating task.
Environment and scope
OpenAI.Codexpackage reports 26.903.9818.0.Read-only evidence: the discussion and successful handoff are still recorded locally
The following original records were verified in the local session JSONL files; these are not a reconstructed instruction or a new dispatch:
send_message_to_threadfor that requirement.isError: false.This rules out an undelivered handoff for this particular exchange. It does not prove that every missing conversation record is intact.
Current history access disagrees with newer durable records
During checks around 2026-09-12 07:16–07:24 UTC:
read_threadfor Thread A returned a newest turn beginning 2026-09-10T12:03:30Z, markedinProgress, without the later exchange above.hasMore: truedid not recover the missing newer section through that older-page check.read_threadfor Thread B returned a newest turn beginning 2026-09-05T09:51:20Z, also markedinProgress, showing an obsolete subtask rather than the current work.The checked history-loading/retrieval path is stale relative to locally persisted newer records. The exact client/server ingestion, replay, pagination, or synchronization failure has not been isolated. Neither normal context compaction nor deletion of all underlying records should be assumed from this symptom.
Impact
Already discussed and accepted requirements appear lost. This undermines review and handoff continuity and can cause instructions to be treated as new, work to be repeated, or old tasks to be reopened. The user is specifically concerned that development decisions and unresolved issues may be forgotten. Actual source-code loss has not been established.
Requested investigation and recovery
No diagnostic restart, cache deletion, transcript rewrite, database modification, task archival, or replacement task was performed during these checks. No private conversation text, source code, project names, task IDs, account data, absolute private paths, raw logs, or databases are attached. This update contains sanitized timestamps and structural evidence only.