Codex usage limits currently interrupt active coding work in a way that can lose execution continuity.
Open 💬 2 comments Opened Jul 6, 2026 by wthernani
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of Codex CLI is running?
v0.142.5
What subscription do you have?
Pro
Which model were you using?
gpt-5.5
What platform is your computer?
Linux
What terminal emulator and version are you using (if applicable)?
Konsole
Codex doctor report
What issue are you seeing?
Codex usage limits currently interrupt active coding work in a way that can lose execution continuity.
The worst part is that once the limit is reached, Codex may refuse even a final cleanup/checkpoint prompt. That means the user cannot ask the agent to write CODEX_PROGRESS.md, summarize the latest work, commit safe changes, or preserve the next action before quitting.
Expected behavior:
- When a usage limit is reached mid-task, Codex should enter a “paused/checkpoint-only” mode.
- It should allow a small final non-reasoning cleanup action:
- write progress file
- print latest git status
- summarize current task state
- optionally commit a WIP checkpoint
- It should persist the active run state automatically.
- After reset, it should resume the same run, not restart from planning.
- There should be an option: “Resume automatically after reset.”
Current behavior:
- Codex hits the limit.
- The user cannot even ask it to checkpoint.
- Resume may restart from plan or reconstruct state poorly.
- The user has to manually recover from disk and babysit the agent.
This is especially bad for long-running coding tasks where the whole point of Codex is autonomous execution.
What steps can reproduce the bug?
Uploaded thread: 019f28eb-2a9a-7903-9abb-fe75bb953c7e
What is the expected behavior?
_No response_
Additional information
_No response_
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I want to add a real-world workflow that shows why execution continuity matters here.
I use Codex for long-running game-development tasks, and a single task can consume 50–100% of my 5-hour allowance.
I have actually developed an improvised way to pause Codex: when my remaining usage gets down to around 20–30%, I start waiting for a Yes/No approval prompt. When one appears, I deliberately leave it unanswered, keep Cursor open, wait for the quota window to refresh, and continue several hours later.
In other words, I am using an approval prompt as an accidental Pause button.
The problem is that I cannot control when the next approval point will appear. It might happen at 20%, at 3%, or not at all before the remaining quota is consumed. Because of that, I sometimes stop working even though I technically still have quota available.
I think a proper Safe Pause/Resume mechanism could solve this without keeping active compute running.
When quota becomes low — or when the user manually requests it — Codex could finish the current safe/atomic step and create a durable checkpoint containing things such as:
current objective and progress;
completed and pending work;
relevant files and modifications;
important architectural decisions;
tests already executed and their results;
Git/worktree state;
the exact recommended next step.
For local IDE workflows, part of that state could potentially be persisted locally, such as a human-readable Markdown checkpoint plus structured state if needed.
Then after the quota resets, Resume Task could verify the repository and continue from that checkpoint.
The distinction that matters to me is:
Git preserves the project. A real Pause/Resume feature should preserve the task.
Pause does not need to preserve active compute. It needs to preserve task continuity.
I am not asking for additional quota here. I am asking for a safer way to stop and resume long-running work within the quota that already exists.