[Usage/Resume] Interrupted Codex sessions waste quota rebuilding context instead of finishing work

What version of the Codex App are you using (From “About Codex” dialog)?

26.903.71938

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex long-running tasks are becoming increasingly inefficient after usage-limit interruptions.

The problem is not only the interruption itself. The main problem is the repeated recovery cost afterwards:

usage limit -> interruption -> rebuild context/state -> partial progress -> usage limit again

When I resume an interrupted task, Codex spends a substantial part of the new allowance reconstructing work that was already done:

• rereading repository files;
• reconstructing previous changes and state;
• rerunning checks/tests;
• reopening browser state;
• determining again which steps are complete and which remain.

By the time useful forward work resumes, a significant part of the new usage allowance may already have been consumed.

This has happened repeatedly in a real Windows/.NET engineering project involving SQLite, browser validation, Excel import, integration tests, Release builds and MSI packaging.

The model is capable of doing the work. The reliability problem is continuity between interrupted sessions.

User impact:

• paid usage is consumed reconstructing previous work instead of advancing;
• long tasks repeatedly fail to reach completion;
• tests, searches, file reads and validations may be repeated unnecessarily;
• I have to manually maintain handoff summaries so Codex does not redo completed work;
• repeated reconstruction increases the risk of duplicated actions, regressions and stale assumptions;
• confidence in Codex for long-running professional engineering work is significantly reduced.

Expected behavior:

When a task is interrupted by a usage limit, Codex should persist a compact structured checkpoint containing at least:

• completed steps;
• pending steps;
• modified files;
• latest test/build results;
• known blockers;
• repository/working-tree state;
• exact next action.

On resume, Codex should verify only what may have changed and continue from the first unfinished step instead of reconstructing large portions of the previous workflow.

This also creates unnecessary compute usage. Repeated repository scans, file reads, browser navigation, tests, builds and model inference over already-established state waste user time, paid quota, backend compute and energy.

Related issues:
#34971
#41220
#25779
#42896
#33634

My report is specifically about the repeated recovery tax after a usage-limit interruption.

I also submitted feedback through the Codex feedback mechanism:

Feedback ID:
01a08091-3667-7230-9329-f18052a4eaa4

The feedback submission was accepted, but the client reported:

"Feedback received, but some diagnostic files could not be uploaded."

There is no user-visible way to verify which diagnostic files were successfully received or to track the status of that feedback ID.

Please investigate how much usage is consumed after resume by context replay, state reconstruction, repeated tool calls, repeated tests/searches and compaction/recovery.

A usage limit is understandable.

Repeatedly paying the reconstruction cost after every interruption is not.

What steps can reproduce the bug?

1. Start a long-running Codex development task that requires repository inspection, file edits, browser/tool use, tests and build validation.

2. Let the task continue until Codex reaches the usage limit and the session is interrupted before the task is fully completed.

3. Resume the same task when usage becomes available again.

4. Observe that Codex must spend part of the new usage allowance reconstructing the previous operational state, for example by:

   • rereading repository files;
   • checking previous changes;
   • reconstructing which steps were already completed;
   • rerunning tests or validations;
   • reopening browser state;
   • rechecking database/runtime state.

5. Continue until useful forward work resumes.

6. Observe that the new usage allowance has already been materially consumed by recovery/reconstruction activity.

7. If the task is interrupted again before completion, resume it once more and observe the same reconstruction cycle.

This produces a repeated pattern:

usage limit -> interruption -> recovery/reconstruction -> partial progress -> usage limit -> recovery/reconstruction again

The issue is most visible in long-running engineering tasks where the stopping point includes state outside the source code itself, such as browser validation, SQLite state, integration tests, generated artifacts or packaging steps.

Feedback reference:
01a08091-3667-7230-9329-f18052a4eaa4

The client also reported that some diagnostic files could not be uploaded.

I do not have a precise session-level token breakdown because Codex does not expose recovery/replay usage separately from productive forward work. That lack of telemetry is part of the problem being reported.

What is the expected behavior?

When a Codex task is interrupted because the usage allowance is exhausted, the task should resume from a compact, durable checkpoint instead of rebuilding large parts of the previous session.

The checkpoint should preserve at least:

• completed steps;
• pending steps;
• modified files;
• latest verified test/build results;
• known blockers;
• repository/working-tree state;
• relevant runtime state;
• exact next action.

On resume, Codex should:

1. Load that checkpoint.
2. Verify only state that may have changed since the interruption.
3. Continue from the first unfinished action.
4. Avoid repeating completed repository scans, file reads, tests, browser validations, database checks or other expensive operations unless there is evidence they need to be repeated.

The usage limit itself is understandable. The expected behavior is that reaching that limit does not create an additional recurring usage penalty simply to reconstruct work that Codex already completed.

Ideally, Codex should also expose enough telemetry to distinguish:

• productive forward work;
• resume/recovery work;
• context replay;
• compaction;
• repeated tool calls.

This would make long-running engineering tasks predictable, auditable and reliably resumable.

Additional information

This report is based on repeated real-world Codex usage on a production-oriented engineering project, not on a synthetic benchmark.

Related issues:
#34971
#41220
#25779
#42896
#33634

Feedback reference:
01a08091-3667-7230-9329-f18052a4eaa4

The feedback submission was accepted, but Codex reported that some diagnostic files could not be uploaded.

There is currently no user-visible way to verify which diagnostics were received or to track the status of that feedback ID.

If maintainers need a specific affected session ID, logs or sanitized diagnostics, I can provide them.

The report names no files, tests, or implementation entry points. Start by reproducing a usage-limit interruption during a long-running task and measure the recovery work after resuming. Done means the task resumes from a durable checkpoint, avoids unnecessary reconstruction, and exposes the requested recovery and productive-work telemetry.