codex resume in CLI should resume completely
Open 💬 4 comments Opened Jun 19, 2026 by poshest
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of Codex CLI is running?
codex-cli 0.141.0
What subscription do you have?
Plus
Which model were you using?
gpt-5.5 xhigh fast
What platform is your computer?
Linux Mint
What terminal emulator and version are you using (if applicable)?
Regular Mint terminal
Codex doctor report
Feedback thread ID 019edc22-11a1-70d1-9a5c-754229580983What issue are you seeing?
I described the issue in the /feedback entry made on my CLI as part of a codex session there. Then you uploaded it and I can't access what I wrote. Don't have time to write it out here again.
Summary: after Ctrl+C, and then codex resume, the session did not fully resume: output from its previous thinking was not there anymore and the current question for command execution was gone. Needed to re-prompt to "start from where you left off"
What steps can reproduce the bug?
Uploaded thread: 019edc22-11a1-70d1-9a5c-754229580983
What is the expected behavior?
It just resumes as if Ctrl+C never happened
Additional information
_No response_
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Resume needs to restore the turn boundary state, not only the visible transcript text.
After Ctrl-C, persist a resume checkpoint with current turn id, last completed event offset, pending approval/tool request if any, and whether the interrupted assistant turn had produced a final answer. On resume, the CLI can show
interrupted_before_tool_approvalorinterrupted_after_completioninstead of forcing the model to infer where it left off.---
_Generated with ax._
This may still be live on
0.147.0, and it might be measurable without needing the lost/feedbacktext.I hit something with the same shape — resume comes back missing recent work — and filed it with numbers as #38169. The short version: on threads that have been auto-compacted many times, a default
thread/resumereturns far fewer turns than the rollout stores, and the ones missing are the newest. It succeeds silently, so it looks like a complete resume.Across 11 threads on one machine,
0.147.0:|
compactedrecords | prompts returned vs stored ||---|---|
| 15, 20, 26, 33 | 19–32% |
| 0, 0, 2, 5, 5, 10, 10 | 91–100% |
Bimodal, nothing in between, and the rollouts themselves are complete — verified across 583 rollout files, none truncated, none lagging the recorded prompt history. So it's reconstruction on read, not loss on write.
Whether that's the same thing you saw after
Ctrl+CI genuinely don't know: your report is0.141.0and interrupt-triggered, mine is compaction-triggered with no interrupt involved. But if your thread was a long-running one, it may be worth checking. #38169 has a short read-only script that prints stored-vs-returned prompt counts for a given thread id and hashes the rollout before and after, so it can confirm or rule this out in one run without exposing any transcript content.The Ctrl+C boundary you described—resume returning without the prior in-progress reasoning or the pending command question—is exactly the kind of interrupted tail I’m looking to test.
I built Codex Rescue as a local-first diagnostic for persisted Codex sessions. It cannot restore reasoning that was never written or automatically replay an unknown command, but it can inspect the surviving rollout for incomplete tool/turn state while leaving the original bytes untouched. Recovery stays fail-closed and may require manual review.
If that session still exists locally, could you try:
pipx install codex-rescue==0.1.0a3codex-rescue sessionscodex-rescue doctor --latestSanitized output is enough—please don’t share the raw rollout, database, prompts, paths, command contents, or secrets.
https://github.com/shleder/codex-rescue