›_ Codex Issues
Codex Issues / #15349

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

Open 💬 6 comments Opened Mar 20, 2026 by aeplay
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

<img width="200" alt="Image" src="https://github.com/user-attachments/assets/b899ec58-a07a-40a1-acf8-ef863fc1cffd" />

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_

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 5 months ago

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

  • #14439
  • #14812
  • #15052
  • #13713
  • #13846

Powered by Codex Action

aeplay · 5 months ago

New session this happened in:

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

marciocamello · 4 months ago

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

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

smith558 · 3 months ago

https://github.com/openai/codex/issues/15709

magjac · 2 days ago

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.

pontelo · 2 days ago

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