Context percentage shows zero after compaction
Resolved 💬 6 comments Opened Jan 17, 2026 by ozan-s Closed Jun 29, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of Codex is running?
codex-cli 0.87.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.2
What platform is your computer?
Darwin 24.6.0 arm64 arm
What terminal emulator and version are you using (if applicable)?
Ghostty
What issue are you seeing?
After compacting conversation, the context percentage indicator shows zero.
• Context compacted
› Summarize recent commits
What steps can reproduce the bug?
Uploaded thread: 019bc711-8999-7be0-ad56-74632c16a11b
What is the expected behavior?
_No response_
Additional information
_No response_
6 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Did the context percentage indicator show 0% context _remaining_ or 0% _consumed_? It should show 0% consumed (or something close to 0%) after a compaction.
It showed 0% remaining.
I had remote compaction on, send the /compact command. While compaction was ongoing, I wanted to queue the next message, but instead of tab, I pressed enter so the message went as a steer. Then when compaction was done, status bar showed "0% context left" and I wasn't able to send a new message.
Hope this helps.
@etraut-openai The repro detail from @ozan-s (pressed Enter during remote compaction so the queued message got sent as a steer) really sounds like a race between the in-flight compaction and user input that leaves the client/session in a bad local state (context remaining = 0% and can’t send).
Potentially-related “context remaining jumps to 0%” reports: #9601 (rollback/backtrack) and #9257 (edit/backtrack). Might be worth consolidating under a single umbrella if the root cause is the same (token usage recompute / context manager state after history mutation).
Possible UX/guardrail: while compaction is in-flight, block sending turns (or buffer locally until the compact completes) so we never send a steer / turn mutation against a moving target. On completion, it may also help to refresh token usage from server-provided counts (or clear to unknown) rather than leaving a 0% sentinel.
We're not able to repro the problem as reported. Are you still seeing this with the latest version of the CLI? If so, please provide more details.
We recently changed our contribution guidelines to indicate that we're no longer accepting unsolicited PRs, so I'm going to close your PR. Let's use this thread to continue the discussion to further analyze the problem if it still exists.
Thanks for reporting this problem. Until recently, Codex used a separate endpoint and server-side logic for compaction. We recently switched to a more robust approach where the compaction logic is moved locally using the same endpoint as normal turns. This eliminates "remote compaction" errors and increases the stability and reliability of compaction operations. If you see further problems with compaction, please use
/feedbackand open a new bug report.