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

What version of Codex is running?

codex-cli 0.80.0

What subscription do you have?

plus

Which model were you using?

gpt-5.2 xhigh

What platform is your computer?

Darwin 23.6.0 arm64 arm

What issue are you seeing?

resume operation contextmismatch with previous exit state; original session file inspection found no issues. After resuming, new codex session exit produced inconsistent session

What steps can reproduce the bug?

{"timestamp":"2026-01-13T15:04:57.524Z","type":"event_msg","payload":{"type":"token_count","info":{"total_token_usage":{"input_tokens":6198727,"cached_input_tokens":6005376,"output_tokens":60840,"reasoning_output_tokens":44372,"total_tokens":6259567},"last_token_usage":{"input_tokens":68364,"cached_input_tokens":68224,"output_tokens":241,"reasoning_output_tokens":0,"total_tokens":68605},"model_context_window":258400},"rate_limits":{"primary":{"used_percent":100.0,"window_minutes":300,"resets_at":1768328670},"secondary":{"used_percent":30.0,"window_minutes":10080,"resets_at":1768915470},"credits":{"has_credits":false,"unlimited":false,"balance":null},"plan_type":null}}}

What is the expected behavior?

Correctly resume to thespecified session and continue the conversation in the same context

Additional information

No response

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

codex is not honoring --dangerously-bypass-approvals-and-sandbox when resumed the session via codex resume <session_id> #9144
After changing model_providers, the resume command cannot view the conversation history of the previous provider #9054
codex resume/resume --all slow to load, no loading indicator #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.

@admk

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.

@admk

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?

@admk

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.

@ignatremizov

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

@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

@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

@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.

Support real Codex credits (balance) display

Harden session fallback, reset command, single-instance, credits (rev…

Navigation Menu

Repository navigation

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

What version of Codex is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What version of Codex is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jan 14, 2026

etraut-openai commented on Jan 14, 2026

n-WN commented on Jan 14, 2026

n-WN commented on Jan 14, 2026

ignatremizov commented on Jan 15, 2026

admk commented on Jan 16, 2026

etraut-openai commented on Jan 16, 2026

ignatremizov commented on Jan 16, 2026

n-WN commented on Jan 16, 2026

pirate commented on Feb 5, 2026

etraut-openai commented on Feb 5, 2026

pirate commented on Feb 5, 2026

etraut-openai commented on Feb 5, 2026

gvelesandro commented on Mar 13, 2026

n-WN commented on Mar 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions