Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Sep 10, 2026
2. github-actions commented on Sep 10, 2026

   

   github-actionsbot

   on Sep 10, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows App 26.901.6511.0] Recent chat history disappears; read_thread stays stale while rollout retains newer messages #44035
   • [Windows Desktop 26.903.8094 / 0.153.4] Recent history unreadable after restart while canonical transcript advances #44054
   • [Windows 26.903.8094.0] Intermediate chat history repeatedly disappears from UI while messages remain in rollout #44119
   • [Windows Desktop + Mobile Remote] newest history page repeatedly regresses to previous-day boundary while a 2.27 GB rollout keeps growing #43600
   • [Windows 26.901.6511.0] Reopened task shows older history although recent final answers remain persisted #43935

   Powered by Codex Action
3. Whitelaughter commented on Sep 11, 2026

   

   Whitelaughter

   on Sep 11, 2026

   More actions

   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.
4. elvis-hao commented on Sep 13, 2026

   

   elvis-hao

   on Sep 13, 2026

   More actions

   I am seeing the same issue on the Windows Codex desktop app. The task remains visible with its title, but opening it shows missing or stale history. Recent user and assistant messages are absent from the UI while the original local JSONL rollout still contains the later messages, including the latest plan. The same behavior has occurred across multiple tasks, and the history/read API can return older content while the rollout retains newer content. This looks like a history projection, index, or cursor problem rather than deletion of the underlying rollout. Please investigate the Windows client/app-server history projection and provide a safe reindex or recovery path that does not require editing SQLite or raw rollout files.
5. Rithmatist commented on Sep 14, 2026

   

   Rithmatist

   on Sep 14, 2026

   More actions

   Codex issue #44362: evidence assessment

   Proposed public-facing draft. Public sources checked September 14, 2026.

   Scope

   This assessment concerns the four claims about reported behavior below from issue #44362. The reported environment was the Windows desktop app, version 26.903.61454, in a local task with an approximately 962 MB session JSONL. Related reports are used to compare observations and assess explanations; they do not independently verify this particular incident.

   The inspected record includes #44362’s body, all three comments and public timeline, together with the cited portions of related reports, diagnostic material, source code, a regression test, release notes and CI results. This was a source review: the reported behavior was not independently reproduced, the linked probes and regression test were not executed, and the original private JSONL, complete reader captures and project records were not inspected. The assessment does not establish the behavior’s prevalence or a common cause across reports.

   Claims assessed

   The propositions selected from the original report are:

   1. Recent conversation turns repeatedly disappeared from the Windows app’s displayed history.
   2. Those missing messages remained in the same task’s local session JSONL.
   3. Two cursor-free read_thread checks returned an older September 9 turn as newest, omitting later messages.
   4. Task continuation showed outdated progress assumptions despite subsequent fixes, tests and discussion.

   Evidence

   Reporter testimony and supplied summaries. The issue describes repeated disappearance during continued work. It supplies four timestamped message summaries from September 10, between 08:49:02 and 09:03:10 UTC+8, and describes the two reader comparisons. These are the reporter’s account of inspecting the records; the public issue does not supply the underlying JSONL messages or complete reader responses for those checks. The reporter explicitly withholds the full transcript because it contains private project information and offers redacted records if needed. Original report

   Corroborating reports and supplied diagnostic comparisons.

   • A September 13 commenter on [Bug] Windows app repeatedly loses recent conversation history while messages remain in the local JSONL #44362 reports matching Windows symptoms across multiple tasks: newer messages remain in local rollout records while the UI and history reader expose missing or older content. This is another participant’s testimony, without attached diagnostic artifacts. Comment
   • Windows issue [Windows App 26.901.6511.0] Recent chat history disappears; read_thread stays stale while rollout retains newer messages #44035 supplies a sanitized cursor-free reader request/response, timestamps, record ordinals and a described comparison against the same task’s indexed rollout. It reports a second stale read. The report calls this a captured occurrence, without a deterministic minimal reproduction or established trigger. Its full transcript was not uploaded. This corroborates the reported discrepancy as a pattern, not the exact checks in [Bug] Windows app repeatedly loses recent conversation history while messages remain in the local JSONL #44362. Report
   • macOS issue [macOS] Reopening a conversation loses recent visible history; task reader returns older turns despite newer local records #44409 distinguishes the reported GUI symptom from its task-reader comparison. Its initial reader discrepancy was observed once, and the report says an independent GUI reproduction was not performed. A later follow-up reports recurrence on version 26.903.71938, plus a separate task with current turn headers but empty item arrays; it does not establish that these discrepancies share a cause. Report, follow-up
   • Another participant reports that affected macOS conversations recovered after an update and restart, whereas restart alone had previously failed. The resulting version is unspecified, and the combined update and restart do not isolate which change produced recovery. The recovery is described as provisional and concerns the conversations that participant checked. Recovery report

   Automated activity and maintainer confirmation. The duplicate suggestion in #44362 is automated. It does not establish duplication, reproduction or diagnosis. No identified maintainer confirmation of #44362’s cause or resolution appears in its three inspected comments. A relevant merged code change is discussed below. Duplicate suggestion, complete comment collection

   Findings

   The classifications below are analytical judgments about the cited evidence. SUPPORTED identifies affirmative evidentiary support with the stated limits; it does not mean that the original incident was independently verified.

   Proposition	Classification	Evidence basis and limit
   1. Repeated disappearance from displayed history	SUPPORTED	The original account has corroboration from another participant’s report in #44362 and related Windows reports. The original display state was not independently inspected.
   2. Missing displayed messages remained in the JSONL	SUPPORTED	The reporter describes identified retained messages; other participants report corresponding persistence-versus-display comparisons. The original JSONL was not inspected for this assessment.
   3. Two cursor-free read_thread checks returned the older September 9 turn as newest, omitting later messages	SUPPORTED	The reporter’s account supports these particular checks. Related reports, including #44035’s sanitized request/response and rollout comparison, corroborate the discrepancy as a pattern; they do not independently verify the two original calls.
   4. Continuation’s assumptions were outdated relative to completed project work	NOT ESTABLISHED	The reporter’s account provides testimonial support. Establishing the claimed divergence requires a comparison between the continuation’s assumptions and the actual project state. The public material lacks the complete continuation and corresponding Git/test evidence needed for that comparison. The first three claims have additional corroboration of the history discrepancy; this missing project-state comparison does not contradict claim 4.

   No selected proposition warrants CONTRADICTED on the inspected evidence. The sources supporting these classifications are the original report and corroborating material identified above.

   Explanations in the record

   Rendering, caching, indexing, pagination, reconstruction, or file size. The original reporter leaves these possibilities unresolved. The record does not isolate any of them as the cause of #44362. Causation: NOT ESTABLISHED. Original unknowns

   A decoder/record-ordinal failure blocking history reconstruction. A participant in #44035 supplies projection counters and an ordinal-mismatch warning, and reports later completed turns remaining in the JSONL while the history reader returned older material. The commenter attributes that occurrence to the failure described in #35746. That attribution is a proposed diagnosis, not a demonstrated causal match to #44362. Projection diagnostic

   A comment in #35746 supplies a synthetic Windows probe and reports that, on codex-cli 0.153.4, certain terminal decimal-valued records caused ordinal reuse, while integer-valued controls did not. A decimal-valued record followed by an ordinary message also continued correctly in that fixture. The script and reported results provide technical evidence for the mechanism in those fixtures. The probe was not executed for this assessment, and its author explicitly had not tested a build containing #42378. The same commenter separately reports recovery of one conversation after local record/checkpoint repair and restart, distinguishing that recovery from a runtime fix; it does not establish a fix for #44362. Experiment, script and recovery distinction

   Publicly inspectable code, test coverage and release inclusion. Merged PR #42378 routes rollout reads through canonical JSON decoding. Its added regression test writes a decimal-valued token-count record, resumes recording, appends a message and asserts consecutive ordinals. The source establishes what the change and test cover; the test was inspected but not executed for this assessment. The official 0.154.0 release lists the PR. PR, commit-pinned regression test, release notes

   The inspected CI run for that commit contains successful and failed jobs, including a failed aggregate required check. Those summaries do not establish the individual regression test’s result or that the decoder change caused the CI failures. CI run, failed required check

   These sources support the described decoder/ordinal mechanism in other reported tests and document a relevant code change. Its role in #44362 and whether that change repaired this particular incident remain NOT ESTABLISHED. The original issue does not supply its backend version, a matching boundary-record comparison or a before/after test against that change.

   Missing terminal turn events despite populated history. Issue #45431 reports similar Windows symptoms in a fresh 3,409,003-byte rollout, alongside a 2,411,663,360-byte history SQLite database. Its supplied counters indicate projection reached that rollout’s end, and its supplied diagnostics describe populated message records while turns remain inProgress without terminal events. The lifecycle explanation is presented as suspected. This report involving a small individual rollout limits extrapolation of large-rollout or stalled-projection explanations across reports; it does not determine their role in #44362. Causal match: NOT ESTABLISHED. Report and diagnostic values

   Other history paths or concurrent failures. Issue #43276 concerns ordinary Chat synchronization into a desktop catalogue; its Windows/web follow-up expressly does not establish the proposed subscription mechanism as the cause of those observations. Issue #44401 reports queue failures alongside history omission and leaves their relationship unresolved. Neither establishes a common cause with #44362. Catalogue report, Windows/web observations, queue/history report

   Update-related recovery. The macOS recovery account supports reported recovery in the conversations that participant checked. It does not isolate the update from the restart, establish lasting resolution or verify a remedy for #44362. A fix for the selected incident: NOT ESTABLISHED. Recovery report

   Missing or unresolved evidence

   • Explicitly withheld: the original full JSONL; the reporter states why it was not attached.
   • Not supplied in the inspected original thread: the offered redacted message records, complete reader captures and the Git/test comparison underlying claim 4.
   • Not located in the inspected material: a controlled reproduction of the original incident, an identified maintainer diagnosis connecting it to a mechanism, or a before/after recovery test for it. Corroborating reports, diagnostic comparisons and synthetic tests of a proposed mechanism were located; these do not independently verify [Bug] Windows app repeatedly loses recent conversation history while messages remain in the local JSONL #44362’s particular incident.
   • Unresolved: the original backend version, trigger, contribution of file size, response to restarting or updating, and whether the related reports share a cause.
   • The inspection covers the cited public records as checked on September 14, 2026, not private discussions, deleted material or a complete revision history. It does not establish that evidence not located here is absent elsewhere.

   Conclusion

   The public record supports a recurring discrepancy between retained local messages and displayed or retrieved history, with corroboration beyond the original reporter. It does not establish #44362’s specific cause, a verified remedy, or its claimed divergence between continuation assumptions and completed project work.

   👍React with 👍1Reacted by Mohammad Jawad
6. teohsinyee commented on Sep 15, 2026

   

   teohsinyee

   on Sep 15, 2026

   More actions

   Repro + working recovery on Windows

   I was able to reproduce this consistently on Windows with:

   • Codex Desktop: 26.908.70816
   • Codex CLI: 0.154.0

   Minimal repro

   1. Create a new conversation in Codex Desktop.
   2. Send two turns:
      • hi 1
      • assistant response
      • hi 2
      • assistant response
   3. Restart Codex Desktop.
   4. Reopen the conversation.

   Actual result

   After restart, only the first turn is visible:

   hi 1
   assistant response
   

   The second turn disappears from both Desktop and codex resume.

   However, the underlying rollout JSONL still contains the complete conversation, including the missing second turn.

   So in my case, this was not data loss. The canonical session data was still intact.

   Recovery that worked

   I fully closed Codex Desktop, backed up:

   ~/.codex/thread_history_1.sqlite
   

   Then I deleted only the affected thread's derived history rows from:

   thread_history_projection_state
   thread_items
   thread_turns
   

   using the affected thread_id.

   I did not modify or delete the rollout JSONL.

   After that, I ran:

   codex resume <thread-id>

   Codex CLI rebuilt the conversation from the existing rollout data and showed the full history again:

   hi 1
   assistant response
   
   hi 2
   assistant response
   

   After reopening Codex Desktop, the full conversation was restored there as well.

   Interestingly, several other previously truncated Desktop conversations also became visible again after this reprojection/reload.

   Conclusion

   In this case, the issue appears to be in the derived local thread-history/projection state after app restart, rather than in the canonical rollout/session data itself.

   It would be very useful to have a supported recovery operation such as:

   codex repair-history
   

   or a Desktop option like:

   Troubleshooting → Rebuild local conversation index
   

   so users do not need to modify SQLite manually.
7. sunkaiyi1221-png commented on Sep 22, 2026

   

   sunkaiyi1221-png

   on Sep 22, 2026 – with ChatGPT Codex Connector

   More actions

   Additional Windows recurrence on 26.915.4065.0

   This issue is still affecting another Windows Codex Desktop user on 2026-09-22.

   • Installed package version confirmed with Get-AppxPackage: 26.915.4065.0
   • Symptom: earlier dialogue content repeatedly stops appearing in the Codex conversation UI.
   • Impact: the user cannot reliably refer back to completed work or prior answers and must ask for full responses to be resent.
   • This is reported as a recurring, long-standing problem rather than a one-off display glitch.
   • No cache, SQLite database, or rollout files were deleted or modified during diagnosis.
   • No private conversation text or user-specific paths are included in this report.

   This confirms that the missing/stale history symptom still reproduces on a newer Windows build than the versions already documented in this thread. Please prioritize a durable fix and provide a supported recovery action such as rebuilding the derived conversation-history index without deleting canonical rollout data.