"edit prev" makes session dead: 0% context left and cannot response any message nor /compact command
Open 💬 13 comments Opened Jan 15, 2026 by SunRunAway
💡 Likely answer: A maintainer (etraut-openai, contributor)
responded on this thread — see the highlighted reply below.
What version of Codex is running?
codex-cli 0.84.0
What subscription do you have?
plus
Which model were you using?
gpt-5.2
What platform is your computer?
_No response_
What terminal emulator and version are you using (if applicable)?
_No response_
What issue are you seeing?
thread id:
- 019bbf7f-6728-7560-8881-59f2b7e5c06a
- 019bbfe0-45c1-73f1-8b38-7777748682fd
What steps can reproduce the bug?
after using edit prev
What is the expected behavior?
_No response_
Additional information
_No response_
13 Comments
Thanks for the bug report. Do you have cause to believe that this is a recent regression? In other words, was this working for you previously?
What is the behavior you see when this occurs? Is there an error message when you attempt to enter the edited prompt (or new prompts)?
I only find and use "edit prev" today so I don't know whether it is a regression.
I just press esc esc and edit the last sent message, and press enter, and it is submitted in tui and no error, then the TUI is unresponsive (edit: not truely unresponsive, just not response any message to me, I can still continue send message...).
Update:
I resume the session (019bbfe0-45c1-73f1-8b38-7777748682fd), and send some message, and it resposes now (with "Context compacted" message ).
Thanks for the update. Are you able to get back into that bad state? Are there specific repro steps that I can follow to get into that same state?
Sorry I tried but can not reproduce with a new session. But the two feedback ids are sessions with long context (~50% left)
I believe this is a recent regression. I use the "esc esc" edit prev feature a lot and now every old conversation I resume ends up with 0% context (this did not happen for me before). If I were to guess what's happening, it looks like all these conversations are being opened "uncompacted", which causes the context to balloon. Just opening an old conversation causes it to be modified, which definitely shouldn't be happening.
I've tried to repro this based on the report, but I'm not seeing the behavior you're describing.
If this is reproducible for you, can you provide a list of concrete repro steps?
Likely this is related to https://github.com/openai/codex/issues/9287. Hopefully it's fixed?
I don't think #9287 fixes this issue, but #9401 likely will.
Maybe i'm misunderstanding, but it looks like #9401 fixes a UI bug? Maybe I misunderstand OP, but I believe this issue is about the session being literally unusable upon reopening a compacted session because there's 0% context left. I thought that's what #9287 fixed. I believe I've also experienced the issue referenced in #9401 though, so good that's being fixed.
Exit codex. Resume by uuid. esc esc to edit prev command - jumps from 63% context left to 17.
Prev time when i had 47% left it jumped to 0.
<img width="1902" height="656" alt="Image" src="https://github.com/user-attachments/assets/e8dfc297-bda7-40d3-8aaa-f2dcc9e20e7d" />
<img width="1878" height="556" alt="Image" src="https://github.com/user-attachments/assets/5bd7435b-55ea-46ac-8110-a9ec0193e84a" />
<img width="1878" height="556" alt="Image" src="https://github.com/user-attachments/assets/7324cf3b-4318-449d-aa1a-2d703c102466" />
Also happening to me. Seems to only happen in conversations that last a while (~50% context consumed without prior compaction). Thread ID: 019bce7d-91e1-73f1-8111-5d910637bf0c
Same or similar issue here.
Doing esc -> esc then updating the prompt doesn't actually rollback the session history but instead appends to later prompts.
It might be related to me ctrl+c a chat response then doing
esc->esc->update.But I used to do it a lot whenever I noticed agent going astray and it has never been an issue. Have started happening from the previous release actually for me (0.92.0), however I've been on 2 week hols and you guys seem to have made a lot of progress so the actual culprit might been hidden in one of the version over that period.
EDIT:
I tried rolling back the version back to 0.84.0 to try and rescue the crashed session but it didn't do nothing really. Probably the damage has already been done and implemented on the storage level with no easy way to rollback via version change.