resuming codex with <session-id> will lose some information

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

• #9144
• #9054
• #7007

Powered by Codex Action

Can you say more about what behavior you're seeing? What do you mean by "original session file inspection found no issues"?

"original session file inspection found no issues" refersto me opening the corresponding Session-xxx.jsonl file with a text editor based on the Session ID, and the file structure appears to be complete.

I'll givean example, please wait a moment

$ codex --yolo

> Coding ~
> 
> /quit
> 
> Token usage: total=749 input=369 output=379
To continue this session, run codex resume 1234-5678

$ codex resume 1234-5678 --yolo

> continue
> [!][!][!] At this point, he would forget what he had done in the previous rounds.

> /quit
> 
> Token usage: total=123 input=456 output=379
To continue this session, run codex resume 7890-4567

I've had this happen a few times, especially after compaction

I found that codex may not be able to pick up from any past chats after auto compact. I almost never needed to compact and recently it just likes to aggressively compact with plenty of context left, so I'm not sure if this bug is recent or not.

I'm still unclear on the problem being reporting here. Could someone please provide a clear description of the problem with repro steps?

@admk, when you say "may not be able to pick up from any past chats", do you mean that codex resume fails? Or are you saying that the agent's behavior is less than optimal after a compaction? You also mentioned something about aggressively compacting with plenty of context left. If that's the case, that sounds different from what's being reported in this thread.

It's a bit difficult to reproduce, but I agree with @admk it may relate to auto-compaction and not the manual compaction.

In my case, let's say you have a long thread. Then auto-compaction happens. You keep working on this thread with new turns. Eventually, you exit. When you next codex resume that thread - the history continues from the moment when compaction occured, losing the context of all turns after the compaction event. I've had this happen twice.

Other times, it may only be one-two turns missing. Sometimes, it's as if it begins from no context at all, even though the entire thread loaded after codex resume - context status shows 100% or near to it, and not the 10-30% expected when the session was closed. New turns show no knowledge of the context of the thread. I've had this happen three times. In this state, it is possible to press esc once/twice to go into the resumed thread history... but once it worked to restore history (or my prompts were good enough to make me assume all is well), or again it's like a new thread continuing with no context of the previous thread.

This is not consistent behavior. I think it may also be related to switching models. There may be several issues here, but all related to the codex resume <session-id> feature.

Edit: https://openai.com/index/unrolling-the-codex-agent-loop/ - it may have something to do with the cache system and how it interacts with compaction?

It's a bit difficult to reproduce, but I agree with @admk it may relate to auto-compaction and not the manual compaction. In my case, let's say you have a long thread. Then auto-compaction happens. You keep working on this thread with new turns. Eventually, you exit. When you next codex resume that thread - the history continues from the moment when compaction occured, losing the context of all turns after the compaction event. I've had this happen twice. Other times, it may only be one-two turns missing. Sometimes, it's as if it begins from no context at all, even though the entire thread loaded after codex resume - context status shows 100% or near to it, and not the 10-30% expected when the session was closed. New turns show no knowledge of the context of the thread. I've had this happen three times. In this state, it is possible to press esc once/twice to go into the resumed thread history... but once it worked to restore history (or my prompts were good enough to make me assume all is well), or again it's like a new thread continuing with no context of the previous thread. This is not consistent behavior. I think it may also be related to switching models. There may be several issues here, but all related to the codex resume <session-id> feature.

That's what I want to say. Thank you for your expression.

I'm experiencing this exact same issue as @ignatremizov described in the latest codex version codex-cli 0.98.0 on macOS with gpt-5.2-codex-high. Attempting to resume sessions that have autocompacted jumps the session history back to the last auto-compaction point, seeminly losing the transcript after that point even though I can see it in the session logfiles.

@pirate, thanks for the clear explanation. I've been struggling to understand what's being reported here. If you run into this, please use the /feedback slash command to upload the session details and post the thread ID here.

I submitted 3 feedback reports on sessions where this happend, but that was before I found this issue. Is there a way I can see the feedback IDs I've reported in the past so I can paste those IDs here? If you can do a lookup by session id, here are a few where I noticed issues:

• 019c2f73-78db-72a1-b16e-bb7527184391 <- the worst one where it keeps happening
• 019c2f73-a5d8-7c23-9e0b-c7bd454ebb0a <- a fork of ^ where it kept happening

Interestingly I've noticed /fork doesn't seem to fix the issue. Attempting to resume from the fork still jumps back to the last autocompaction, and later messages on the fork seem to mutate the original session somehow. (or at least the UI makes it seem like it, it's possible it's just showing the new messages continuing from the wrong point in the history)

If I run both the fork and the original session in parallel the agents get confused because they seem to still be writing to the same session file? They see each other's messages interleaved in the history, it's almost like they failed to fork despite /status showing different session ids? Very strange.

Thanks for investigating either way!

@pirate, thanks. The feedback IDs are the same as the session IDs. I can see the session details you uploaded earlier, so we're good.

@n-WN I'm researching failures where codex resume appears to load a session but comes back with the wrong effective context. Your thread is a strong example because the transcript file seems intact, yet the resumed agent behaves as if earlier work never happened, especially after auto-compaction.

If you're open to it, I'd value one short written postmortem here: https://www.agentsneedcontext.com/agent-failure-postmortem

I'm looking for five specifics: what the agent was trying to do, what context was missing after resume, where that missing context should have lived, what workaround you used, and what it cost. No pitch, just research.

@n-WN I'm researching failures where codex resume appears to load a session but comes back with the wrong effective context. Your thread is a strong example because the transcript file seems intact, yet the resumed agent behaves as if earlier work never happened, especially after auto-compaction. If you're open to it, I'd value one short written postmortem here: https://www.agentsneedcontext.com/agent-failure-postmortem I'm looking for five specifics: what the agent was trying to do, what context was missing after resume, where that missing context should have lived, what workaround you used, and what it cost. No pitch, just research.

It sounds interesting, but it's been so long that I've forgotten the session number.