›_ Codex Issues
Codex Issues / #21073

Feature Request: Auto-resume CLI session when usage limit resets

Open 💬 10 comments Opened May 4, 2026 by ndycode

What variant of Codex are you using?

CLI

What feature would you like to see?

When Codex hits the usage limit mid-task, the error already tells me exactly when the quota resets (e.g. "try again at 6:34 AM"). If that reset time falls while I'm asleep, the information is wasted — the task just dies and waits for me to wake up, find the session, and re-issue the prompt.

<img width="548" height="219" alt="Image" src="https://github.com/user-attachments/assets/0fd2c533-1613-468f-8732-31499c642afb" />

I'd like Codex to automatically continue the session at the reset time, without me being there.

Behavior:

  1. Turn fails with usage limit reached.
  2. Codex reads the reset time it already knows about (resets_at in UsageLimitReachedError).
  3. Instead of erroring out, Codex sleeps until that time and then re-runs the same turn.
  4. I wake up to a finished or in-progress task instead of a frozen one.

Why this is basically free to implement:

The reset timestamp is already structured data in the protocol (codex-rs/protocol/src/error.rs → UsageLimitReachedError.resets_at) and the session already updates rate limits on this error (codex-rs/core/src/session/turn.rs ~line 1075). Today we just throw the timestamp away and crash the turn. The ask is: use it.

Make it opt-in so nothing changes for existing users:

codex --auto-resume-on-limit

or in ~/.codex/config.toml:

[usage_limits]
auto_resume = true

That's it — that's the feature.

Additional information

The screenshot shows the exact message in question: "try again at 6:34 AM". I was asleep at 6:34 AM. The agent could have just kept going.

Related: #15788 covers the App-side queueing of new prompts on usage limit. This is the CLI/session-resume sibling — same idea, different surface.

View original on GitHub ↗

10 Comments

RunsenXu · 1 month ago

Yes. Need this.

ndycode · 1 month ago

@etraut-openai need this though hope you consider.

diogovalada · 1 month ago

It shouldn't just be on quota reset. There should also be automatic recovery from internet connection failures.
Codex retries to reestablish a connection, but these do nothing if all the retries are done before the connection recovers.

https://github.com/openai/codex/issues/22033

ndycode · 1 month ago

oh god please add this feature. :(

AaronZLT · 1 month ago

+1

Lodenk · 1 month ago

Please enable this!

tristan666666 · 1 month ago

Adding one datapoint from the external-tool side while a native Codex fix is pending: I built Agent Island for this exact sleep/AFK case.

It runs outside the CLI as a small macOS watchdog for selected Claude/Codex sessions:

  • shows the live session state in the MacBook notch: running / waiting for user / stuck
  • can auto-resume a selected long-running session when it is able to continue again, by sending a configured short message such as continue

This is not a replacement for the native resets_at handling proposed here; Codex should still support this directly. But if anyone needs the workflow today, the repo is here:

https://github.com/tristan666666/agent-island

alqtest · 16 days ago

We need this please

arikon · 8 days ago

Confirmed the same gap specifically with a durable Codex Goal in the macOS app.

Observed state after quota exhaustion:

{
  "status": "usageLimited",
  "tokensUsed": 174563,
  "remainingTokens": null
}

The UI reported the reset time, but reaching that time did not generate a continuation turn. The goal only resumed after a new user message. This is particularly surprising for Goal mode because the durable objective and continuation contract are still present, yet usageLimited behaves as a terminal scheduler state rather than a timed waiting state.

Suggested Goal-specific behavior:

  1. Persist resets_at together with the goal state.
  2. Transition usageLimited -> waiting_for_quota.
  3. At resets_at plus bounded jitter, revalidate quota and enqueue exactly one synthetic continuation.
  4. Preserve the full durable goal objective and audit the resume event.
  5. Use bounded retries/backoff and stop on user-input, authorization, destructive-action, or repeated-blocker states.
  6. Expose an opt-in App/Goal setting and a visible “will resume at …” control with cancel/resume-now actions.

This complements the CLI proposal here: the same primitive should work for App Goal continuations, not only a foreground CLI process sleeping until reset.

saaranshM · 1 day ago

I ended up building this as an external tool while waiting for native support:

https://github.com/saaranshM/unsnooze

Codex turned out to be a little fiddly because there's no event when a session stops due to a usage limit. Instead, unsnooze watches the terminal for the exact limit banners used by Codex and handles all of the reset formats it emits:

  • "Try again at 3:51 PM"
  • Absolute dates
  • Relative durations like "in 4 days 20 hours"

When the limit expires, it resumes the original session with codex resume <session-id>.

The pleasant surprise was discovering that the rollout files under ~/.codex/sessions contain the actual reset timestamp as a Unix epoch. That means the wait is based on the exact server-provided reset time rather than parsing human-readable text, and it works equally well for the CLI, the IDE extension, and the ChatGPT desktop app because they all write the same rollout data.

It's MIT licensed, installs with:

```bash id="v1h2tm"
npm i -g unsnooze


It also supports Claude Code and several other AI coding CLIs.