Repository navigation
Codex context burn remains high after compaction/new session #29947
Description
What version of Codex CLI is running?
codex --cli 0.142.0
What subscription do you have?
Pro 5x
Which model were you using?
gpt-5.5
What platform is your computer?
Linux 7.0.11-76070011-generic x86_64 x86_64
What terminal emulator and version are you using (if applicable)?
Cosmic
Codex doctor report
Doctor/update behavior:
I was asked to check for an update and run codex doctor before filing. codex doctor
completed in the managed Linux Codex session, but showed sandbox/network-related
failures: 13 ok, 1 idle, 4 notes, 3 warn, 1 fail. The failure was provider
reachability/DNS blocked inside the sandbox, plus optional Socket MCP reachability
and update probe warnings.
Then the update check/npm update attempt hung with no output under restricted
network and the terminal/session crashed before I could capture codex doctor
--json. No stray codex/npm/node update process was left running afterward, and the
install still reports codex-cli 0.142.0.What issue are you seeing?
Main bug:
Context burn remains abnormally high after compaction and even after starting a new session. After compacting and starting a totally new session, context was already around 46% left. This happened repeatedly today and forced multiple compactions much sooner than normal along with higher token burn and much slower work flow than usual for what we are working on.
What steps can reproduce the bug?
Uploaded thread: 019efc4e-c11e-72c3-ba71-68712bc5dbf5
We did multiple compacts, hit our 5 hour cooldown faster than usual. I allowed the cooldown, restarted my session fully compacted and ready to continue and on one tool update we had to compact again. We decided to start a brand new fresh session to see if that would fix the issue and got to one briefing and one tool update and had 46% left to compact. Workflow was still slow and token burn is heavier than normal for the type of work we are doing right now updating our security read-only tools from cyber security blogs.
What is the expected behavior?
On a normal day we don't come close to our 5 hour cooldown doing this type of work. We move much faster updating than we have been because the tools are established it is just adding new content. Normally we can knock these out during my morning but today it has been all day compacting.
Additional information
This started with the new update and is the first time we have encountered this type of compacting issue, slow responses, and length of time to complete a daily ritual / standard practice.
Activity
github-actions commentedon Jun 25, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Dragon-Lady commentedon Jun 25, 2026
Thanks. I reviewed the suggested duplicates. This may be related, especially to the
broader compaction/token-burn reports, but I’m leaving this open for now because
this report is specifically for Linux Codex CLI 0.142.0 and includes an uploaded
thread ID showing abnormal context burn after compaction/new session.
Additional distinct detail: while trying to complete the bug form requirements,
codex doctor completed with sandbox/network-related failures, then the update/npm
step hung under restricted network and the terminal/session crashed before I could
capture codex doctor --json.
Uploaded thread: 019efc4e-c11e-72c3-ba71-68712bc5dbf5
Dragon-Lady commentedon Jun 25, 2026
We are running in Linux in terminal and don't have access to the Codex App:
devansh-jain-18 commentedon Jun 26, 2026
This matches another current Desktop/worktree pain point tracked in #30194: compaction can appear to run, but the effective context usage does not meaningfully go down, so the thread remains near-full and the next action still hits context pressure.
The key expected behavior is that compaction should materially reduce effective context load, not just produce a compacted marker/event. If it cannot reclaim enough space, Codex should surface that clearly and offer a recovery path such as a fresh-context thread attached to the same existing worktree/files/git state.
Dragon-Lady commentedon Jun 26, 2026
We checked the worktree and it is clean and not an issue. Tibo mentioned publicly on X "The Codex team is investigating issues where some accounts are seeing faster usage draining than intended. We believe this is related to some abuse & fraud prevention mechanisms that we have that might be overflagging. " which fits our issue pretty cleanly.