When a Large Codex Task Gets Interrupted, Don’t Just Say “Continue”

| Application program | 1 Reads

Copyright Notice: This article is an original work licensed under the CC 4.0 BY-NC-ND license. If you wish to repost this article, please include the original source link and this copyright notice.
Source link: https://v2know.com/article/1371

When using Codex for large tasks, there is one problem that becomes increasingly important:

The task may still have a long way to go, while your Codex usage allowance is almost exhausted.

For example:

  • Remaining usage: 1%

  • Estimated usage required to finish: 20%+

If the limit is reached, the current task may be interrupted.

The interruption itself, however, is not necessarily the biggest problem.

Changes Codex has already written to the workspace usually still exist.

The more important question is:

How should Codex safely resume the task afterward?

The obvious response might be:

Continue.

For a large task, though, that is not always the safest instruction.

Why “Continue” Is Not Enough

A large task can leave the workspace in a complicated intermediate state.

Codex may already have:

  1. Read the requirements

  2. Modified several files

  3. Implemented part of the solution

  4. Run tests

  5. Discovered problems

  6. Started fixing those problems

Then the task gets interrupted.

If the next Codex turn simply relies on conversational context and tries to continue from memory, several things can go wrong:

  • Already completed work may be repeated

  • Existing changes may be overlooked

  • A valid intermediate state may be mistaken for a problem

  • Correct changes may be overwritten

  • Existing files may be regenerated unnecessarily

  • Uncommitted work may be reverted

This leads to an important rule:

The actual state of the workspace is more trustworthy than the model's memory of the previous turn.

A Better Codex Resume Prompt

After an interrupted task, I now prefer using something like this:

Continue the previous unfinished task.

Before making any new changes, first inspect the actual current state of the workspace, including:

  • git status

  • git diff

  • newly created or modified files

  • work already completed in the previous run

  • unfinished or partially completed work

  • failed tests, temporary files, incomplete implementations, or other intermediate states

Treat the current contents on disk as the source of truth. Do not rely only on memory from the previous conversation.

After identifying the actual current progress, continue from the real interruption point and finish the original task.

Do not:

  • redo work that has already been completed

  • revert or overwrite existing correct changes

  • reset the workspace merely because its current state differs from what you expected

  • use git reset, git checkout --, git restore, or similar commands to discard changes unless you have verified that those changes are incorrect and genuinely need to be removed

If the previous run stopped in an incomplete state, repair that state in place and continue from the existing work.

Finally, complete the original validation and testing requirements.

Why This Prompt Is Useful

The valuable part is not really the phrase:

Continue the previous task.

The important parts are the constraints around it.

1. Inspect the Workspace First

Having Codex check:

git status
git diff

before making additional changes forces it to reconstruct what actually happened.

Instead of starting from model memory, it starts from the real project state.

2. Separate Completed Work from Unfinished Work

One of the biggest problems after an interrupted Agent task is duplicated work.

Codex should explicitly determine:

  • what is already complete

  • what remains unfinished

  • what was left half-finished

That makes continuation much more reliable.

3. Prevent Accidental Reverts

This may be the most important part.

Sometimes Codex sees a workspace that differs from what it expected.

Without additional instructions, it may try commands such as:

git restore
git checkout --
git reset

to return the repository to a cleaner state.

But during a long-running task, those uncommitted changes may actually be the valuable output from the previous run.

It is therefore useful to explicitly tell Codex:

Do not discard existing work just because the current workspace differs from your expectations.

An Even Better Approach: Maintain a HANDOFF.md

For very large tasks, there is an even more reliable strategy.

At the beginning of the task, ask Codex to maintain a file such as:

HANDOFF.md

or:

PROGRESS.md

The file can contain:

  • task objectives

  • completed work

  • current work in progress

  • remaining tasks

  • important design decisions

  • discovered issues

  • test results

  • recommended next steps

Then, if any of the following happens:

  • Codex usage is exhausted

  • the session is interrupted

  • Codex crashes

  • the task is manually stopped

  • you switch models

  • you move to a new Codex session

the next Agent can read HANDOFF.md, inspect git diff, and reconstruct the current state much more reliably.

Conclusion

For small Codex tasks, simply saying:

Continue.

is usually fine.

For a task that has already modified many files, performed complex analysis, or gone through multiple rounds of implementation and testing, a more deliberate recovery process is much safer.

A good recovery flow looks like this:

Inspect the current workspace
↓
Check git status / git diff
↓
Identify completed work
↓
Identify unfinished and intermediate work
↓
Protect existing correct changes
↓
Resume from the actual interruption point
↓
Run the final validation again

The main principle is simple:

Do not let Codex guess where it stopped from memory. Make it inspect the actual workspace first.

For large Agent-based tasks, this small habit can prevent a surprising amount of duplicated work and accidental damage.

This article was last edited at