Repository navigation
[Windows App 26.901.6511.0] Recent chat history disappears; read_thread stays stale while rollout retains newer messages #44035
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Installed Windows package: OpenAI.Codex 26.901.6511.0 (queried with Get-AppxPackage; not copied from About).
The executable used by the running app server reports codex-cli 0.153.4.
What subscription do you have?
Not collected for this report.
What platform is your computer?
Windows x64, OS version 10.0.26200.
Local Codex task in a Git workspace; PowerShell.
Observed on 2026-09-09, UTC+08:00.
What issue are you seeing?
Recent conversation history disappeared from the user's view during a long-running local Codex Desktop task. A read-only check also found a concrete discrepancy: the app's read_thread tool returns an older task turn as the newest turn, while the indexed JSONL rollout for the same task still contains later user messages and continues receiving records.
The user can still send messages and the agent can continue work, but the returned history does not include the later conversation. This report establishes missing/stale exposed history, not confirmed deletion of the underlying conversation data.
Sanitized evidence
The task identifier was obtained from CODEX_THREAD_ID and used for both the app-tool read and the exact SQLite row lookup. Identifiers and message contents are omitted from this public report.
At 2026-09-09T03:39:16Z, a read without a pagination cursor returned:
{
"request": {
"turnLimit": 1,
"includeOutputs": false
},
"threadStatus": "active",
"page": {
"order": "newest_first",
"limit": 1,
"hasMore": true
},
"newestReturnedTurn": {
"status": "inProgress",
"startedAtUtc": "2026-09-08T17:07:19Z",
"completedAt": null
}
}The returned turn contains an older feature request and only its initial work items. A separate read with turnLimit: 3 returned that same stale newest turn and two earlier turns.
A read-only state_5.sqlite lookup and inspection of its referenced rollout showed:
- The task row exists and
archived = 0. - The referenced rollout exists and was approximately 54.7 MB.
- A later user message is present as a top-level
response_itemuser message at2026-09-08T19:41:38.751Z, ordinal3621. - The user's report of missing history is present as a top-level
response_itemuser message at2026-09-09T03:12:55.553Z, ordinal6127. - The tail contains valid JSON records through
2026-09-09T03:39:22.786Z, ordinal6186.
Those message checks inspected actual user-message records, not text quoted inside tool output. The full transcript was not uploaded.
What steps can reproduce the bug?
This is a captured occurrence, not yet a deterministic minimal reproduction:
- Use a local Codex Desktop task over an extended development session, with multiple follow-up messages and tool calls.
- Continue sending messages after earlier work.
- Observe that recent conversation history is missing from the task view.
- Read the same task with the app's
read_threadtool, no cursor, andturnLimit: 1or3. - Observe that the newest returned turn is from an earlier request.
- Inspect only that task's indexed rollout read-only; later user messages are still present.
The exact action that first triggered the divergence is unknown. A restart, update, compaction, or migration has not been established as the cause.
What is the expected behavior?
The task view and history-reading API should expose the latest persisted conversation in the correct order. If history loading or indexing fails, the app should show an actionable error and provide a safe way to reload/rebuild the visible history without losing the underlying transcript.
Additional information
- Two app-tool reads showed the same stale latest-turn boundary.
- No session files were moved, no SQLite records were edited, and the app was not restarted during this investigation.
- The symptom suggests a divergence somewhere between persisted rollout data and exposed history, but the responsible layer has not been localized.
- Related report Paginated history drops valid flattened rollout records and reuses ordinals #35746 concerns paginated history/projection inconsistencies. The same root cause has not been established here.
- The task remains usable for new agent work; losing the conversation trail makes it difficult to review previous decisions and completion reports.
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
howieab2-svg commentedon Sep 9, 2026
Additional occurrence on Windows desktop, reported on 2026-09-09 (UTC+08:00). Posting this diagnostic summary at the affected user's request.
User-reported symptom: Parts of an ongoing, multi-day conversation repeatedly appear to disappear, making it difficult to revisit decisions and completed deliverables. The task remains usable for new messages.
Checks performed in this occurrence:
read_threadtool surfaced much older conversation content, inconsistent with recent work.This establishes retained local content alongside the reported incomplete history. It does not establish deletion, a particular projection/indexing failure, or the exact cause of the
read_threaddiscrepancy. Pagination behavior and the first triggering action have not been isolated, and a deterministic minimal reproduction is not available. The installed app version was not reliably captured for this occurrence.Exporting the existing public-facing messages to local HTML/Markdown provided access to the work, but did not repair the in-app history. The user is asking for this recurring issue to be investigated. This comment contains only a diagnostic summary; no private conversation text, project files, session identifiers, or raw logs are attached.
astral303 commentedon Sep 9, 2026
I am pretty sure this is a duplicate of #35746. All chat history is now "paginated."
Sam-24-dev commentedon Sep 9, 2026
Additional sanitized reproduction from Windows on 2026-09-09. This looks consistent with the stale-history / retained-rollout behavior described here.
Environment / surfaces observed:
Observed behavior:
codex resume --all.rollout-*.jsonlstill present and recently written. The file was ~142.9 MB and its latest timestamp reached2026-09-09T17:25:41.030Z.response_itemmessages withrole=user|assistantfrom the rollout. It confirmed real user/assistant turns from approximately 11:56 through 12:25 local time (UTC-5), including the most recent work that is missing from the reconstructed UI/CLI history.This therefore appears to be retained canonical transcript data + stale/incomplete reconstructed history, not deletion of the recent messages. The fact that the same stale boundary is visible in VS Code, Desktop, and CLI may help narrow this below the individual UI layer (for example history projection/indexing/app-server/session reconstruction).
One secondary observation: while another Codex surface still had the thread open, CLI resume initially returned
thread already has an active writer (code -32600); after closing the other surfaces, the thread could be resumed, but the recent history was still missing. I mention this only as context, not as a claimed cause.No private conversation text, usernames, project paths, thread/session IDs, credentials, or raw logs are included here.
lolson777 commentedon Sep 10, 2026
Additional sanitized occurrence on a newer Windows build, posted at the affected user's explicit request.
Environment
OpenAI.Codex 26.903.8094.010.0.26200Observed behavior
read_threadinterface returns a September 8 turn as the newest turn, markedinProgress, with only three items and an early command failure.2026-09-09T22:22:21.915Z, followed bytask_completeat2026-09-09T22:22:22.530Z, and a latertask_startedrecord at2026-09-10T00:23:54.260Z.read_thread.1,500,237,404bytes. That may be useful diagnostic context, but it is not established as the cause.This confirms a discrepancy between persisted task records and the history exposed by the app; it does not establish deletion of the underlying messages or identify the faulty layer.
Expected
All persisted user-visible exchanges should remain accessible in the task UI and through task-history reads. If reconstruction/indexing fails, the app should show a recoverable error and provide a safe reindex/rebuild path.
No raw transcript, task ID, private project text, credentials, business screenshots, or local paths are included. The affected user can provide narrowly scoped diagnostics through a private support channel if maintainers specify what is needed.
tang-t21 commentedon Sep 10, 2026
The same bug, history is in jsonl file, but UI doesn't show the latest turn.
mikehudson2 commentedon Sep 10, 2026
Additional confirmed Windows reproduction with the projection layer localized. I investigated this occurrence at the affected user's request.
Environment
codex-cli 0.153.4.0.149.0-alpha.4.1.Canonical rollout remains intact
compactedrecords.task_completeevents are present well beyond the point exposed by the UI/history API.Materialized history is stale
thread_history_projection_statestopped withnext_rollout_ordinal = 106921and byte offset571834233.thread_turnscontains 1,266 projected turns, with its latest completed turn ending at ordinal106920at2026-09-10T11:14:04Z.read_threadrequest withorder = newest_firstreturns that older turn as newest, while the canonical JSONL contains many subsequently completed turns.The internal log gives a concrete failure
failed to project durable rollout: thread history projection expected ordinal 106930, got 106929This warning was emitted 456 times during the read-only investigation and continued after restarting the app. No SQLite or JSONL files were edited.
This appears to establish the same boundary-ordinal failure described in Paginated history drops valid flattened rollout records and reuses ordinals #35746, which predicts a replayed boundary at
next_ordinal - 1that permanently blocks projection catch-up. It also localizes this issue below selective UI rendering: the canonical writer succeeds, while the durable-history projection rejects the suffix andread_threadserves the stale projection.User impact
No raw transcript, message text, task ID, credentials, local username, or project path is included. A supported projection rebuild/recovery path would be valuable for already-affected tasks.
Whitelaughter commentedon Sep 11, 2026
Possibly related reports, in case they help correlate the failure modes:
#43276 — ordinary Chat conversations can exist in fresh account history but be absent from the desktop local catalogue after the Chat update subscription is unmounted.
#44035 — Windows: newer conversation records remain persisted locally while read_thread exposes stale older history.
#44362 — Windows: recent messages remain in the session JSONL while read_thread returns older turns as newest_first.
#44409 — macOS: recent persisted records similarly exist while reopening/task reading exposes older history.
I also posted independent Windows/web synchronization observations from our RETIS tests in #43276. Those tests distinguish Recents/sidebar visibility, explicit conversation search, persisted conversation state, and information actually retrievable by the assistant.
These may not share one root cause, but the reports seem useful to compare because they independently show divergence between different representations/retrieval paths for conversation history.
BradleyElder commentedon Sep 13, 2026
Additional sanitized Windows occurrence on Codex Desktop
26.908.4834.0.During a session wrap, the assistant emitted a completed timeline item containing a Markdown start prompt with a fenced text block. The local rollout was approximately 41 MB. Read-only inspection confirmed that the exact assistant
output_textitem was persisted, followed bytask_complete.The user reported immediately afterward that the item was not visible in the desktop timeline. Two subsequent minimal fenced-code-block tests were also emitted and remained invisible, including after leaving voice mode. Later ordinary replies continued to render, so the task itself remained usable.
For a direct comparison, the same small fenced code block was saved as a Markdown workspace file and opened in Codex's right side panel. The user confirmed that it rendered visibly there. This narrows the observed failure: the Markdown/code-block content is renderable in the side panel, but the corresponding emitted inline timeline items are absent from the conversation view.
This establishes persisted assistant output plus a timeline-specific visibility failure; it does not establish deletion or the responsible layer. The current conversation had no matching
Turn not found for evententry in the checked logs. Two nearby errors with that wording belonged to an auto-compaction event in another conversation, so they are not attributed to this occurrence.No session database or rollout file was modified. Private prompt content, project details, local paths, and task identifiers are omitted. The exact start prompt remains recoverable from a Git-tracked handoff file.
humiao commentedon Sep 19, 2026
Additional macOS evidence for the same stale-history symptom.
Environment:
In a long-running local desktop task, the visible conversation history stopped at an older prefix. A read-only history request with newest-first ordering also returned old turns instead of the most recently persisted turns.
Sanitized local verification found:
thread/turns/listand repeatedthread/items/listresponses with no returned error code, but the later conversation still did not appear in the task UI.I also checked for the ordinal discontinuity described in #45010. No within-file ordinal gaps or duplicate adjacent ordinals were found in the six inspected rollout files, so I cannot confirm that this occurrence has the same root cause.
Expected behavior:
Privacy note: no task IDs, usernames, private paths, project names, transcript content, screenshots, databases, or raw logs are included.