Repository navigation
Codex usage limits currently interrupt active coding work in a way that can lose execution continuity. #31205
Description
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
Activity
github-actions commentedon Jul 6, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
alexlopesluz10-svg commentedon Aug 28, 2026
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.
perro20120812 commentedon Sep 6, 2026
I have the same concern, and I would like to clarify one important
aspect of the checkpoint/resume behavior.
What I am looking for is not only resuming the conversation or
reconstructing the task from its previous context. I would like Codex
to preserve the exact execution state at the moment the task is
interrupted.
For example, if Codex is in the middle of editing a file and a usage
limit is reached, the checkpoint should preserve:
context
The desired behavior would be:
Task interrupted
→ Restore execution checkpoint
→ Continue from the exact interrupted state
rather than:
Task interrupted
→ Reconstruct context
→ Re-read files
→ Repeat tool calls
→ Continue
This would reduce redundant context processing, repeated file inspection,
tool calls, latency, and token usage.
This is especially important for long-running autonomous coding tasks.
For example, if Codex was halfway through generating or editing a file
when the limit was reached, I would want it to continue from that exact
execution point after the limit resets, rather than reconstructing the
previous state and starting the operation again.
I think this is an important distinction between ordinary session
resume and true execution checkpointing.