Repository navigation
Feature Request: Auto-resume CLI session when usage limit resets #21073
Description
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.
I'd like Codex to automatically continue the session at the reset time, without me being there.
Behavior:
- Turn fails with usage limit reached.
- Codex reads the reset time it already knows about (
resets_atinUsageLimitReachedError). - Instead of erroring out, Codex sleeps until that time and then re-runs the same turn.
- 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 = trueThat'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.
Activity
[-]Feature Request: Auto-resume CLI session at usage-limit reset time (so I don't have to wake up at 6:34 AM)[/-][+]Feature Request: Auto-resume CLI session when usage limit resets[/+]RunsenXu commentedon May 23, 2026
Yes. Need this.
ndycode commentedon May 25, 2026
@etraut-openai need this though hope you consider.
diogovalada commentedon May 26, 2026
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.
#22033
ndycode commentedon Jun 2, 2026
oh god please add this feature. :(
AaronZLT commentedon Jun 5, 2026
+1
Lodenk commentedon Jun 13, 2026
Please enable this!
alqtest commentedon Jul 4, 2026
We need this please
arikon commentedon Jul 12, 2026
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
usageLimitedbehaves as a terminal scheduler state rather than a timed waiting state.Suggested Goal-specific behavior:
resets_attogether with the goal state.usageLimited -> waiting_for_quota.resets_atplus bounded jitter, revalidate quota and enqueue exactly one synthetic continuation.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 commentedon Jul 19, 2026
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:
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/sessionscontain 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:
It also supports Claude Code and several other AI coding CLIs.
201224tlx-sketch commentedon Aug 31, 2026
I built an unofficial external reference implementation while native support is still under discussion:
https://github.com/201224tlx-sketch/codex-auto-resume-watchdog
The watchdog reads quota state through Codex app-server (
account/rateLimits/read) and waits forprimary.resetsAt, then verifies that quota is actually available before resuming the same session once. This avoids using repeatedcodex exec resumecalls as a quota poll, which can append duplicate continuation turns.It also restores the original
session_meta.cwd, persists session/state/log data across restarts, handles reset propagation delay, and backs off when the thread still has an active writer. It has been tested primarily on Windows and is an external wrapper, not an official OpenAI implementation. Native Codex integration would still be cleaner and more reliable.leomleao commentedon Sep 7, 2026
Please we need this! Claude got there first.
farquer commentedon Sep 8, 2026
Please we need this! Claude got there first.
Chang-Jin-Lee commentedon Sep 9, 2026
Two things that may help whoever picks this up: the request is fragmented across five open issues, and a competing CLI shipped it since this was filed.
Five open issues are asking for the same behaviour, split by surface rather than by mechanism:
/Goalafter a 5h limitdocs/contributing.mdasks people to "upvote an existing request that describes the same need", so the split is working against the process rather than against the idea — four months of demand reads as five small asks instead of one. Consolidating onto whichever of these you prefer would make the signal legible, and this one has the most specific proposal.The mechanism underneath them is one thing, not five: a turn ends with a known
resets_at, and nothing waits for it. Scoping the fix where that timestamp already lands — the session layer, per this issue's own pointer atUsageLimitReachedError.resets_at— covers CLI, Goals and long-running tasks together. Solving it per surface is what produced five issues.Claude Code shipped exactly this on 2026-08-17, three months after this issue was opened, so nobody on the thread has seen it. From its changelog for
2.1.234, verbatim:Two details in that shape are worth borrowing regardless of what gets built here. It defaults to on, with the off switch in config rather than a flag you have to remember at launch — which matters because the case the feature exists for is the one where you are not at the keyboard to pass a flag. And the resumption is a continuation of the existing session rather than a fresh turn; in practice the resumed context is told to continue the interrupted work and not to redo what already completed, which is the difference between resuming and restarting.
That second point is the part worth specifying before implementing.
--auto-resume-on-limitas proposed in the body would re-run the same turn; re-running a turn that had already written files or run commands is not always safe. A continuation prompt that states what was interrupted is cheaper to get right than a replay.acts-1631 commentedon Sep 9, 2026
Seriously needed! Constantly hitting usage limits now that the 5h window is back.
amir1376irani commentedon Sep 10, 2026
+1
p30arena commentedon Oct 2, 2026
We want this ASAP
quanhuayang commentedon Oct 3, 2026
I would also like this feature in Codex CLI. My installed version is 0.159.3.
The requested workflow is: when a task is interrupted because the five-hour rolling usage allowance is exhausted, preserve the current session and unfinished task, wait until the applicable allowance becomes available again, and automatically continue without requiring me to type "continue" or manually resume the session.
This would make long unattended tasks much more useful: reaching the usage limit would pause the work rather than require the user to return at the reset time.
An opt-in setting or session action, a visible waiting status/reset countdown, and a way to cancel the scheduled continuation would be helpful. Automatic continuation should preserve the existing model and permission settings, respect any other exhausted quota, and continue from the saved task state rather than blindly repeat already completed actions.
Please consider adding native support for this workflow. This is a feature request, not a claim that I have reproduced a new defect.
songyb111-gachon commentedon Oct 5, 2026
For people on the Codex desktop app on Windows, there is now an unofficial external tool for this too: Codex Auto Resume - https://github.com/songyb111-gachon/codex-auto-resume-windows
When a conversation stops on a usage limit, it waits for the reset time Codex itself reports, checks that usage is really available again and that nothing newer happened in that conversation, and then sends one continuation to that exact conversation (by its thread UUID) through the official
codex queuecommand - no GUI automation, nothing typed into the window. It also recovers failures it can name (429, network, 5xx, dropped streams), waits rather than sends whenever it is unsure, and never resends a message that may already have been delivered.To be clear about the scope: Windows 10/11 and the Codex desktop app only, not the CLI yet. A conversation the app has unloaded (after an app restart, for example) is resumed once you open it again.
It is MIT-licensed and not affiliated with OpenAI. Native support would still be the better answer; this is only meant to bridge the gap until then.
piemvibes-hue commentedon Oct 8, 2026
I hit this constantly — overnight tasks dying on stream disconnects / limit resets / WebSocket-reconnect limbo (#30933). Until official auto-resume lands I built a small watchdog: it watches
~/.codex(rollout JSONLs + the sqlite stores), classifies the failure, and resumes the exact thread —codex queuefor threads a surface holds open,codex exec resumefor dead/exec threads (queued messages to dead threads just sit unread in queue_1.sqlite, verified). Usage limits wait for the actualresets_attime. It then verifies the thread is producing events again and pings you over ntfy.sh/webhook if it gives up. MIT, zero deps: https://github.com/piemvibes-hue/agentwatch