How Codex Can Resume Automatically After a Rate Limit

Long coding sessions sometimes hit a rate limit in the middle of useful work. The clean way to handle that is not to restart the task from memory later. It is to schedule a thread resume at the reset time, then let Codex continue from the latest repo state.

This note shows the pattern: a small resume prompt, a known wake-up time, and a safety checklist that protects generated output and local-only working material.

Minimal Version

When a rate-limit message gives a reset time, ask Codex to resume this thread at that time.

Example:

Resume this thread at 11:34pm Australia/Melbourne.
When you wake up, check git status, continue from the latest user request, run verification, and commit completed work.

The important details are:

• use the exact reset time
• keep the resume attached to the current thread
• tell Codex to check the repo state first
• include any project-specific safety rules, such as keeping generated deploy output untracked

Resume Data Flow

flowchart TD
  Limit["Rate limit reached"]
  Reset["Read reset time"]
  Heartbeat["Create thread heartbeat"]
  Wake["Thread wakes later"]
  Inspect["Check git status and latest commit"]
  Continue["Continue latest unfinished request"]
  Verify["Run tests or build checks"]
  Commit["Commit completed work"]

  Limit --> Reset --> Heartbeat --> Wake --> Inspect --> Continue --> Verify --> Commit

Detailed Explanation

Codex cannot automatically detect a future rate-limit reset as an event. It can, however, schedule a thread wake-up for a specific time.

That wake-up should be a heartbeat attached to the current conversation. A thread heartbeat is useful because it preserves the working context: the latest user request, the repository path, the recent commits, and any project rules already established in the session.

The resume prompt should be small and operational:

Resume the current work from the latest user request.
Check git status and the latest commit before editing.
Continue any unfinished implementation or verification.
Run the project checks before reporting completion.
Commit completed work with a focused message.

For static-site work, the prompt should also include the public deployment boundary:

Keep generated deploy output, local notes, environment files, and service state untracked.
Run npm run build when changing public content or site code.

That matters because the public site is generated during deployment, while local notes and service state should not be committed.

Helper Script

The repo can include a small helper script that prints a safe resume instruction.

node scripts/resume-template.mjs "11:34pm" "Australia/Melbourne"

Output shape:

Resume this thread at 11:34pm Australia/Melbourne.

When you wake up:
- Check git status and the latest commit first.
- Continue from the latest user request, not an older task.
- Keep generated deploy output, local notes, environment files, and service state untracked.
- Run npm run build when changing public content or site code.
- Commit completed work with a focused message.
- Report what changed and anything still blocked.

You can edit the time, timezone, and checklist for each project.

Safety Checklist

• Do not put secrets in the resume prompt.
• Do not include local-only notes in the resume prompt.
• Prefer one wake-up for rate-limit recovery.
• Ask Codex to inspect the repo before editing.
• Ask Codex to verify before committing.
• Keep generated deploy folders untracked when the platform builds them.

Takeaway

Automatic resume works best when it is boring: schedule the wake-up, inspect the repo, continue the newest request, verify, commit, and report. The trick is not the automation itself. The trick is giving the resumed agent a clean operating checklist.