I released a free Mac beta for Codex interruptions. I need people to break it.

Spidy boy — Fri, 16 Oct 2026 19:47:20 +0000

I'm building Continua because I got tired of leaving a Codex task running and coming back to find that it had stopped hours earlier.

I now have a free experimental macOS beta, and I'm looking for developers who use Codex Desktop on Mac and are willing to test it.

The aim is narrow: keep track of a task interrupted by a genuine usage limit, wait until usage is available again, then attempt to continue the same task only if the original session and environment can be verified. It doesn't bypass quota or approve commands on your behalf.

Where it stands

The beta is available for macOS 13+ (Apple silicon and Intel).
In a real usage-limit test, the app safely preserved the interruption but did not successfully resume when usage returned.
I've patched the retry logic, but a fresh, fully unattended interruption → reset → continuation cycle still needs validation.
The build is unsigned and not Apple-notarized. Check the installation instructions before installing.

So I'm not looking for nice reviews. I'd rather hear what doesn't work.

What I'd love tested

Does installation/onboarding make sense?
Does the app identify an actual Codex interruption, rather than an unrelated error?
Does it point to the correct session instead of an older or unrelated task?
Does it refuse to continue if Codex is waiting for approval, or if you've sent newer instructions?

Try the free beta · Installation guide · Feedback and bug reports

I'm building Continua independently; it isn't an official OpenAI product. If you're using Codex on macOS, what would you need to see before trusting unattended continuation?

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

Spidy boy — Sun, 11 Oct 2026 10:56:49 +0000

Update — 13 October 2026: Continua v0.1.0-beta.1 is now available as a free experimental Mac beta. No purchase, subscription or licence key is required. This build currently supports Codex Desktop on macOS 13+ (Apple silicon and Intel).

I'm specifically looking for people who run longer Codex tasks and occasionally hit usage limits. If you try it, I'd much rather hear what breaks than get a polite review.

It's still experimental: unattended quota recovery, physical sleep/wake recovery and some resource behaviour are still being tested. The app is unsigned and not Apple-notarized, so please read the installation guide first.

Download the free beta · Installation guide · Give feedback or report a bug

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:

Nothing has been submitted. Keep the original task pinned and retry environment verification within its bounded recovery window.
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?

Watch the 30-second Continua introduction for Mac. It uses actual app captures; it is not a recording of a completed recovery cycle.

The free experimental Mac beta is available now. If you use Codex Desktop on a Mac, download Continua and share your feedback.

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.

DEV Community: Spidy boy