Codex hit its usage limit. Resuming safely is harder than clicking Continue.

I use Codex for long coding tasks. The annoying part is coming back and discovering that the task stopped while I was away. Even when usage becomes available again, I still need to notice the interruption and check what should continue.

That is the problem behind Continua, a macOS utility I am building. The intended flow is simple: preserve an interrupted Codex task, wait for actual usage availability, check the environment, then resume that same task.

Getting that last step right is less simple. A real test today found a failure that my automated tests had not caught. Here is what it taught me about building this kind of automation.

A reset time is not permission to send a message

The tempting implementation is a timer: remember the reset time, wait, send “continue.”

But several things can change during that wait:

• The original Codex process can exit or be replaced.
• The user can switch projects or open another session for the same task.
• The user can send a new instruction, making the old continuation obsolete.
• Usage might still be unavailable when the timer expires.
• A previous submission may have succeeded even if its acknowledgement was lost.

A timer answers when to check again. It does not establish that a particular task is safe to resume.

In Continua, I separate the saved interruption from the permission to submit a continuation. The saved record identifies the original task and environment. Before resuming, the controller needs fresh evidence that those still match.

The process needs to be the right process

Finding a Codex session file on disk does not prove that it is the active session. There can be old files for the same task, and session filenames can change between upstream versions.

The current implementation checks the original live writer and the rollout file it actually has open. It also checks the task metadata and project scope. When ownership is absent or ambiguous, submitting a continuation would be a guess.

This is a useful distinction for any desktop automation: “I found a record” and “I found the live owner of this record” are different claims.

Today's failure: a safe stop that never retried

Today's test reached a genuine usage-limit interruption. Continua preserved it, but later entered a review state because it could not establish the pinned task's host unambiguously.

After usage returned, the original writer could be verified again. Continua still did not resume. The review state had become permanent.

I have not established why that earlier host observation was ambiguous. The evidence does establish the failure that mattered: uncertainty before submission became a state that never retried after the environment recovered.

The fix distinguishes two situations:

1. Nothing has been submitted. Keep the original task pinned and retry environment verification within its bounded recovery window.
2. A submission may already exist. Reconcile its outcome before considering any further submission. Retrying blindly could send the same instruction twice.

That boundary matters more than making the UI say “ready.” The controller must preserve enough evidence to know which situation it is in.

New user instructions win

While diagnosing the failure, I sent a new instruction in the original chat. At that point, resuming the old interrupted turn would have been wrong.

On the installed patched build, replaying the saved checkpoint detected that newer activity and cancelled the stale continuation. No continuation was submitted.

That was the correct outcome for this case. A recovery tool should respect the user's latest instruction, even when it means declining to automate something it previously intended to do.

What I can claim today

The host-retry fix is implemented and installed. The engine suite passed 336 tests, and 27 isolated native-controller checks passed. The installed build also demonstrated safe cancellation after newer user activity.

Those results do not prove unattended recovery through a fresh real usage-limit cycle. Today's original cycle failed, and the patched build still needs a new genuine interruption, restored availability and verified continuation in the same task.

I am keeping Continua in early testing rather than presenting those automated checks as a completed launch.

A checklist for automating interrupted work

If you are building something similar, I would check these boundaries before optimizing the happy path:

• Save the exact task and scope at the interruption.
• Verify the live environment again before acting.
• Treat temporary uncertainty differently from a possibly completed submission.
• Keep submission identities so an uncertain acknowledgement cannot cause a duplicate.
• Cancel stale work when newer user activity appears.
• Bound retries and make unresolved outcomes visible.
• Test the packaged app against real events as well as fixtures.

Continua does not provide extra quota or bypass usage limits. It is an independent project, not an OpenAI product. Its goal is to reduce the babysitting around a supported Codex workflow after usage genuinely returns.

If you use Codex on a Mac: when a long task stops, is the bigger problem noticing the interruption, deciding what to resume, or trusting an automatic continuation?

I am looking for a few early testers and workflow feedback. Continua early access.

Disclosure: I am building Continua. This article was prepared with AI writing assistance from the project's implementation and recorded test evidence. It describes an early build, not a completed recovery demonstration.