Skip to content

Loss of large amount of recent conversation turns / history / context after app restart #15349

Open
Open
Loss of large amount of recent conversation turns / history / context after app restart#15349
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archiving

Description

@aeplay
aeplay
opened on Mar 20, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.318.11754 (1100)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

Frequently after restarting Codex Desktop, several conversations loose a large amount of recent history completely, and for history before the lost part, tool calls and file changes are missing.

Image

This is an example where the conversation is cut off about 1 day's worth of work from where it should be. And between every paragraph visible in the screenshot.

I have a hunch that the "cutoff point" roughly but not exactly aligns with past compaction points.

Interestingly the local log files for each conversation still contain all the turns (I'm able to regain most context by asking Codex in a new conversation to recover information from the log file). So this seems to be a loading/replay issue not a persistence issue.

I would really appreciate if you could look into this as it is a severely productivity-breaking and frustrating bug.

What steps can reproduce the bug?

My guess:

Have a long conversation over multiple compaction steps, then reload the app.
Only happens to some conversations, cause unclear

Example conversation IDs where this happened:

019cdf08-912c-7132-86c7-acc1b960dde9
019c986b-0a68-7bc2-b9b6-4e2a4e2a3fec <- happened here multiple times!
019cfe1e-9bd3-7371-a335-6f1dff7dd62c

Will provide more conversation IDs as follow up comments as this keeps happening.

What is the expected behavior?

Every conversation should resume to the last turn that was made it in under all circumstances.

Additional information

No response

Activity

  1. aeplay
    added
    appIssues related to the Codex desktop app
    on Mar 20, 2026

  2. github-actions commented on Mar 20, 2026

    @github-actions
    github-actionsBot
    on Mar 20, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. aeplay commented on Mar 21, 2026

    @aeplay
    aeplay
    on Mar 21, 2026
    Author

    New session this happened in:

    019cfe1e-9bd3-7371-a335-6f1dff7dd62c

  4. marciocamello commented on Apr 1, 2026

    @marciocamello
    marciocamello
    on Apr 1, 2026

    do it this and solve ok on windwows or similar for mac/linux

    setx CODEX_HOME 'C:\Users\your_user.codex'

  5. ambrosino-oai
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    and removed
    appIssues related to the Codex desktop app
    on Apr 1, 2026
  6. ambrosino-oai
    added
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Apr 25, 2026

  7. smith558 commented on May 28, 2026

    @smith558
    smith558
    on May 28, 2026

    #15709

  8. magjac commented on Aug 25, 2026

    @magjac
    magjac
    on Aug 25, 2026

    I can reproduce this on Linux, twice in unrelated worktrees.

    Environment:

    • Linux 6.8.0-138-generic x86_64
    • installed Codex CLI 0.149.1

    Observed sequence:

    1. A long-running conversation had an interrupted turn whose visible endpoint was Conversation interrupted - tell the model what to do differently.
    2. I resumed the same conversation and continued through many later user, assistant, and tool turns. The later work completed successfully and produced Git commits.
    3. After restarting Codex, reopening the conversation showed the transcript only through that much older interrupted turn. All later visible turns were absent, so the conversation appeared to have rolled back to a stale checkpoint.
    4. Restarting again produced the same stale transcript endpoint.

    This has now happened in two independent repository worktrees (fake-target-in-real-video and metaquest3). In the first case I recovered operationally by asking the still-running agent for a summary and starting a new conversation/worktree.

    The underlying data does not appear to be deleted. On the second occurrence I searched ~/.codex/sessions/.../rollout-*.jsonl, and exact text from turns missing in the resumed UI is still present. The repository changes and commits created during those missing turns are also intact.

    This therefore looks like a resume/replay or transcript-hydration problem near an interruption/compaction boundary, rather than failure to persist the rollout. I can provide sanitized rollout/log excerpts or thread IDs if useful.

  9. pontelo commented on Aug 25, 2026

    @pontelo
    pontelo
    on Aug 25, 2026

    II updated the desktop app version to 26.803.81509, and it resolved the issue. Version from August 10, 2026.

  10. scraptechindustries commented on Sep 2, 2026

    @scraptechindustries
    scraptechindustries
    on Sep 2, 2026

    Independent Windows reproduction on a newer build, with evidence that this is
    partial UI reconstruction rather than transcript deletion.

    Environment

    • Windows 11 25H2, build 26200.9168, x64
    • Codex Desktop 26.831.2377.0
    • Previous observed build before the update/restart: 26.825.6671.0

    What happened

    Immediately after the app updated and restarted, one long-running task displayed
    only a fraction of its earlier chat text. The current turn and subsequent work
    continued normally, so the model/backend still appeared to have working context.

    Sanitized measurements

    • The task rollout remained present at 507,767,521 bytes (484.24 MiB) and kept
      growing after the restarted app opened it.
    • A bounded read-only task query returned older completed turns, reported
      hasMore: true, and showed the current turn as active.
    • In the captured post-restart log, the affected task received:
      • 24 successful thread/read responses
      • 32 successful thread/turns/list responses
      • 41 successful thread/items/list responses
      • zero task-tagged non-null error codes
    • Initial thread/items/list responses completed in about 22–40 ms, so the
      app-server was not obviously blocked retrieving those pages.
    • The same renderer log contained 38
      ResizeObserver loop completed with undelivered notifications errors while the
      task was open and updating. These errors are global rather than task-tagged, so I
      am treating them as a renderer/layout lead, not proof of the exact cause.

    The active writer held the rollout against a second reader, so I did not interrupt
    the task or claim a new full JSONL integrity count. The available evidence still
    establishes that older history remained available beyond what the desktop rendered.

    Expected behavior

    After an update/restart, the desktop should progressively display the complete
    paginated history of a valid task. A large task should not silently present a
    truncated-looking transcript while continuing from hidden history.

    Privacy

    No task ID, title, transcript text, prompt content, local path, account identifier,
    raw log or screenshot is included. Sanitized aggregate evidence can be provided
    privately if maintainers want it.

  11. mpbdn commented on Sep 2, 2026

    @mpbdn
    mpbdn
    on Sep 2, 2026 – with ChatGPT Codex Connector

    I saw a very similar failure yesterday (2026-09-01), but in a long-running ChatGPT Project conversation, not Codex Desktop. I’m adding this only as a cross-product signal because the symptom is unusually close.

    The conversation had been active for roughly three weeks and contained a lot of project work. At some point, a substantial part of the most recent context (roughly the last day of work) was no longer available to the assistant, while older/high-level context from the same conversation was still retained. This was not an intentional deletion or reset.

    What made it especially disruptive is the recency pattern: losing old detail after compaction would be understandable, but losing the newest day while retaining older summarized state breaks task continuity much more severely.

    I can’t confirm that ChatGPT Projects and Codex Desktop use the same compaction/replay path, so I’m not claiming the same root cause. But the observed failure mode looks very similar to the report here: a long conversation, likely multiple context-management/compaction cycles, followed by loss of a large recent tail.

    Expected behavior: any compaction/replay strategy should strongly preserve the newest conversation tail (ideally verbatim or with much higher retention priority) and summarize progressively older history first.

  12. wrobelda commented on Sep 4, 2026

    @wrobelda
    wrobelda
    on Sep 4, 2026

    Happened twice to me using CLI and a very long, important conversation is almost entirely gone.

    However, the transcript on the filesystem is unaffected (at 125MiB!), so this isn't a data loss issue, at least not here.

  13. wrobelda commented on Sep 4, 2026

    @wrobelda
    wrobelda
    on Sep 4, 2026

    OK, I just confirmed this is fixed by #42369

  14. code-n-go commented on Sep 11, 2026

    @code-n-go
    code-n-go
    on Sep 11, 2026

    Just happened to me. COMPLETELY unacceptable. How TF are we to trust anything this app does now? Literally, HALF A WEEK from my project just disappeared from the Desktop App (Codex) after updating it to Version 26.903.71938. I can't trust ever using this crap again... knowing this can happen.

    Codex’s history index is broken for this task. I now have the actual error:
expected ordinal 22788, got 22787
The index is stuck at a September 8 record, preventing subsequent saved messages from appearing in the history view. Your underlying conversation log continues through today.
This confirms an app history-processing failure. I have identified it, but have not repaired it. The [diagnostic evidence] and [readable history] are saved.

  15. wrobelda commented on Sep 11, 2026

    @wrobelda
    wrobelda
    on Sep 11, 2026

    Just happened to me. COMPLETELY unacceptable. How TF are we to trust anything this app does now? Literally an HALF A WEEK from my project just disappeared from the Desktop App (Codex) after updating it to Version 26.903.71938. I can't trust ever using this crap again... knowing this can happen.

    It's not gone, it's just not shown by the app and it's fixed by #42369. Which was release in 0.154.0

  16. code-n-go commented on Sep 11, 2026

    @code-n-go
    code-n-go
    on Sep 11, 2026

    Just happened to me. COMPLETELY unacceptable. How TF are we to trust anything this app does now? Literally an HALF A WEEK from my project just disappeared from the Desktop App (Codex) after updating it to Version 26.903.71938. I can't trust ever using this crap again... knowing this can happen.

    It's not gone, it's just not shown by the app and it's fixed by #42369. Which was release in 0.154.0

    Thank you. I was aware due to what I tagged below my initial message. Still didn't do much for the heart attack and mini-stroke I experienced before I found all that out, lol. I obviously was still going through it when I wrote my initial message (I was a little pissed, obviously). > months of "Update PTSD" isn't something I now look forward to... but here we are.

  17. wrobelda commented on Sep 12, 2026

    @wrobelda
    wrobelda
    on Sep 12, 2026

    obviously was still going through it when I wrote my initial message (I was a little pissed, obviously).
    months of "Update PTSD" isn't something I now look forward to... but here we are.

    I was the same and after this I made sure that my Kopia rules backup transcripts in my projects

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions