Session logs data loss
Resolved 💬 5 comments Opened Apr 6, 2026 by Yohe-Am Closed Apr 22, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of Codex CLI is running?
0.166.0
What subscription do you have?
Plus
Which model were you using?
gpt-5.3-codex
What platform is your computer?
Linux 6.19.10 x86_64 unknown
What terminal emulator and version are you using (if applicable)?
Alacritty
What issue are you seeing?
Sometimes, when I close the CLI and try to resume a previous session, I find that it hasn't saved some sections of the log. In the latest instance, 2 days of messages are gone. It's like the session logs didn't flush at exit.
What steps can reproduce the bug?
Doesn't happen always but this is not a SIGKILL issue. Natural exit where the CLI shows me the resume prompt and token usage stats also suffers this issue.
What is the expected behavior?
Session data should be flushed to the session logs every message to avoid data loss.
Additional information
_No response_
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
You mentioned that you're using version 0.166.0. That's not a valid CLI version. Can you confirm which version you're using?
When you say "session logs", are you referring to the thread rollout file or the CLI log file?
The thread rollout doesn't include all details that are in the live view of the session. Could that account for the behavior you're seeing?
This is the first report that we've heard of this.
Can you offer more detailed repro steps? Without that, we won't be able to investigate further.
Sorry, I meant 0.116.0.
And yes, I meant the rollout file., I understand that not all details are visible on resume like the diff sections but that's not what I mean here. Full history loss from a certain point forwards as in I'd forked at a certain point but the fork wasn't saved.
In the latest instance when I lost two days of history, I went and checked the relevant file in $HOME/.codex/sessions and indeed, it's not been modified in two days. It does sound like an fsync issue to me.
I can't seem to reproduce it reliably but if I catch a hint of that could be done, I'll report back here.
This seems like a dupe of #15709. I've uploaded the relevant feedback
019d5651-adfd-7282-8024-9224b8916f9d.I'm closing this until I issue resurfaces on more recent versions.