Status bar spikes to 100% left while working

Resolved 💬 10 comments Opened Nov 22, 2025 by duckSquirrelPilot Closed Jan 31, 2026
💡 Likely answer: A maintainer (guidedways, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

codex-cli 0.60.1

What subscription do you have?

pro

Which model were you using?

gpt-5.1

What platform is your computer?

Darwin 22.6.0 arm64 arm

What issue are you seeing?

When running a prompt, the status bar suddenly begins displaying "100% left" instead of what the context should actually be. After the work is done and the response has been rendered, the display reverts to e.g. "47% left" or whatever (presumably) the context usage actually is.

Note that on certain previous versions of codex cli, there was actually a bug I noticed where a conversation can actually get corrupted and the context really does get set back to 100% (as if you've started a new conversation).

The behavior for this issue is different- the display of "100% left" is only transient. However, because the codex UI is rather opaque in terms of how it stores and exposes context to the user, I'm uncertain whether it truly is only a UI issue or if there actually is some corruption of the context window. I didn't notice this behavior on recent previous versions, so I think this is a recent regression.

What steps can reproduce the bug?

Use codex-cli 0.60.1 and work normally. At some point, you will see the behavior I described.

What is the expected behavior?

Expected behavior is for "XX% left" to display accurately at all times. Ideally, the user is given more information about what's actually happening in the context window to gain confidence (e.g. a command similar to /status that will display stats such as messages sent by user and by AI agent, # tool calls made, tokens outputted by message (maybe even a histogram)), but it seems this single number in the status bar is all we can go off of, so it should be accurate and trustworthy.

I don't know how things are implemented in the backend, but crucially, the user should be able to "inspect" the actual real context window or at least be confident that stats displayed about the context window are fully accurate. This means that the mechanism of showing this information must be directly tied to the actual live context window (and not through some other pipeline that is decoupled from what's actually happening in the context window).

Additional information

_No response_

View original on GitHub ↗

10 Comments

guidedways contributor · 8 months ago

@duckSquirrelPilot this isn't a bug - when you say 'work' do you mean /review?

Either way you'll see this when Codex spawns off a fresh new codex _child session_ (like a sub-agent) where it gets allocated a new context window (100% empty). When that work finishes, the child session ends and what you see is the _actual_ context window size you were left with originally.

The only thing opaque is the fact that Codex does not communicate this very well - there's no way to tell why the context window is suddenly 100% and why it's back to being 47% (what it started off with). It should probably indicate when it's running work within a sub-session.

duckSquirrelPilot · 8 months ago

I'm just sending a normal message (no slash commands), not /review. I don't think there is any child session being spawned for the prompts I'm sending.

It's possible that the context window jumping to 100% is "expected" and not a bug, but in any case I think some clarification here would be good (and the UI definitely could be improved). Also, it's strange that previous versions didn't have this behavior, which is my primary concern that a more serious regression has occurred.

guidedways contributor · 8 months ago

@duckSquirrelPilot oddly I'm not seeing this, did you test this with the latest version as well?

guidedways contributor · 8 months ago

I've build codex from source (current commit) and don't see it, perhaps this is partially fixed, pending release?

I say partially because a moment ago I saw it say 79% and then on the next prompt suddenly jumped to 82%. I thought it's perhaps micro optimizing input / output tokens but this might just be a bug?

duckSquirrelPilot · 8 months ago

So I have noticed and gotten used to the fact that when going from gpt 5.1 to e.g. gpt 5.1 codex, the context remaining increases slightly. This makes sense because the gpt-codex models have shorter system prompts than the "general" gpt models. Did you change models when you saw it go from 79% to 82%?

I don't know if this jump to 100% is related, but I think it might be happening mostly when I switch models (I do it so frequently I didn't really notice the connection before).

duckSquirrelPilot · 8 months ago
@duckSquirrelPilot oddly I'm not seeing this, did you test this with the latest version as well?

Yes I see it still on 0.63.0

guidedways contributor · 8 months ago
Did you change models when you saw it go from 79% to 82%?

No, I've been using a single model all day.

I don't know if this jump to 100% is related, but I think it might be happening mostly when I switch models (I do it so frequently I didn't really notice the connection before).

This sounds plausible, it could be a session continuity bug where the context usage isn't being passed between turns when you switch models.

etraut-openai contributor · 5 months ago

I think this has been fixed in the latest version. If you're still seeing it, please use /feedback to open a new bug report.

guidedways contributor · 5 months ago

@etraut-openai I'm seeing this still on and off with the context % jumping around, some times it'll say 53% then in the next prompt suddenly 70%, then back to 48% while outputting thinking tokens. On v0.93

etraut-openai contributor · 5 months ago

@guidedways, that sounds somewhat different from what's described in this bug. Please open a new one using /feedback.