openai / openai/codex

Persistent Auto-Resume After Usage Cooldown for Goals and Long-Running Tasks

Open
#43,605 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

CLI enhancement rate-limits session
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

What variant of Codex are you using?

CLI

What feature would you like to see?

Feature Request: Persistent Auto-Resume After Usage Cooldown for Goals and Long-Running Tasks

Summary

Codex should be able to automatically resume Goals and other long-running agent tasks after a usage-limit cooldown/reset, without requiring the user to manually return and press Resume or type continue.

This would make Codex substantially more useful for genuinely autonomous engineering work.

Current Problem

Codex can now handle increasingly large engineering goals that may run for hours:

  • repository-wide refactors
  • migrations
  • debugging campaigns
  • test/fix/test loops
  • application modernization
  • dependency upgrades
  • large feature implementations
  • autonomous Goals

However, these tasks can encounter the usage limit before the Goal itself is complete.

At that point Codex stops.

Even when the quota becomes available again later, the task remains paused until the user manually returns.

For a long-running autonomous agent, the quota boundary should ideally behave like a temporary execution checkpoint, rather than the end of the task.

Proposed Behaviour

Add an option such as:

☑ Automatically resume after usage reset

When enabled:

  1. Codex begins executing the Goal normally.

  2. If the account reaches its usage limit, Codex safely checkpoints the current execution state.

  3. The Goal enters a state such as:

    Paused — usage limit reached

  4. Codex records the known/reset eligibility time.

  5. Once usage becomes available again, Codex automatically resumes the same Goal.

  6. It continues from the existing execution state rather than creating a new task or requiring the user to re-enter the prompt.

  7. This continues across multiple usage windows until one of the following occurs:

    • the Goal is completed;
    • the user cancels it;
    • Codex encounters a genuine blocker requiring user input;
    • an approval/permission decision is required;
    • repository/workspace state has changed in a way that makes automatic continuation unsafe.
Example

A user starts:

Pursue Goal: migrate this repository to the new architecture, run all tests, repair regressions, verify the application end-to-end, and continue iterating until the acceptance criteria pass.

Codex works for several hours.

Then:

Usage limit reached — available again at 03:14

Instead of terminating the autonomous workflow:

Goal paused — waiting for usage availability.

At 03:14:

Usage available — automatically resuming Goal.

Codex then continues working.

No user interaction should be necessary.

This Should Apply Beyond /goal

Ideally this execution model should eventually apply to:

  • Pursue Goal
  • long-running agent sessions
  • orchestrator/subagent workflows
  • repository-wide tasks
  • test-and-repair loops
  • autonomous debugging sessions
  • queued tasks

In other words, temporary quota exhaustion should pause execution, not destroy task continuity.

Persistence

For true long-running operation, the paused task should ideally survive:

  • Codex application restart
  • terminal/CLI restart
  • computer sleep
  • temporary network interruption
  • Codex process restart

Where architecture permits, the persisted task could contain:

  • Goal ID
  • execution checkpoint
  • working directory/repository
  • current plan
  • completed steps
  • remaining steps
  • Git/worktree state
  • pending tests
  • usage-reset timestamp
  • permission/approval state
Safety

This should not bypass usage limits.

Codex should make no model calls while usage is unavailable.

It should simply wait until usage becomes available again and resume normally.

Additionally, automatic continuation should stop if:

  • user approval is required;
  • permissions have changed;
  • the repository has materially changed externally;
  • credentials have expired;
  • a destructive action requires confirmation;
  • continuing from the previous state cannot be safely guaranteed.
UX

Something as simple as:

Long-running Goal

☑ Auto-resume after usage cooldown

Status:

Running → Usage limit reached → Waiting until 03:14 → Resuming → Running

There could additionally be:

Maximum automatic resumes: Unlimited / 1 / 3 / Custom

and:

Stop auto-resume after: 6h / 12h / 24h / Goal completion

Why This Matters

The increasingly capable Codex agent model makes tasks that span several hours or even multiple usage windows realistic.

Requiring a human to return simply to type:

continue

adds no meaningful safety or information.

For an explicitly authorised long-running Goal, Codex should treat temporary usage exhaustion like any other recoverable infrastructure condition:

checkpoint → suspend → wait → resume.

This would make Goals considerably more useful for overnight work, large refactors, repository migrations, test-driven repair loops, and other autonomous engineering workflows.

Acceptance Criteria
  • User can opt into automatic resume for a Goal.
  • Usage-limit exhaustion checkpoints rather than terminates the Goal.
  • No model usage occurs while quota is unavailable.
  • Codex automatically detects when usage becomes available.
  • Execution resumes from the existing Goal/context.
  • Completed work is not unnecessarily repeated.
  • Multiple cooldown/resume cycles are supported.
  • User can cancel the waiting Goal at any time.
  • Approval-required actions still pause for the user.
  • Unsafe/stale execution state prevents automatic continuation.
  • UI clearly distinguishes Running, Waiting for quota, Blocked, Cancelled, and Complete.

The key principle is:

A usage cooldown should pause an autonomous Goal, not end it.

Additional information

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no files, tests, or entry points. Start by locating Goal execution and usage-limit handling in the CLI, then map how task state is persisted and resumed. Done means an opt-in Goal can checkpoint, wait without model calls, resume across cooldowns, and stop safely for cancellation, approval, or stale state.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
ai-infra-agents, cli
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
32/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.