Codex can refuse a turn while its last quota update still reads 99%, or before the session receives any quota notification. Those failures lost a reset time the server already knew, hiding the existing resume-at-reset and snooze actions. Fixes #14169.
The reset selection prefers current exhausted windows, accepts 99% only when none is fully exhausted, and discards expired observations. Both external CLI and managed Codex sessions can use the provider instance’s published limits before any main-allowance session data arrives. That fallback remains provisional: the first session notification replaces or clears it. A known session-derived reset is preserved, and later session data can fill an unknown reset. Model-specific quota buckets cannot claim the main allowance.
This takes over the original work by voltcrash in #18721, preserves the contributor commits, and merges current main. The original fallback-on-null behavior was replaced because stale published data could become a permanent reset. No client or contract changes.
Verification:
pnpm exec vp test run apps/server/src/provider/codexUsageLimits.test.ts apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.test.ts --maxWorkers=2: 194 passed.tsc-rs --noEmit passes with Effect suggestions only. git diff --check passes.Proof is deterministic app-server replay through the real adapter, not a live quota refusal. No screenshots apply to this server-only change. Real accounts, macOS, Windows, iOS, Android, and Electron desktop were not verified on this headless Linux VM. Existing historical failures are not repaired.
Implementation: GPT-6.1 Sol; tests: GPT-6 Astra; independent reviews: Claude Opus 5.5 and GPT-6 Sol. Harness: Codex / Claude in T3 Code.
Verdict: Approved at 98815ea
Macroscope's review found this PR approvable — This is a focused Codex server bug fix that restores reset timestamps for existing usage-limit recovery, including 99% and pre-notification cases. The implementation is localized, uses the existing published limits contract, and is covered by targeted tests without changing defaults, schemas, or quota enforcement.
You can add or adjust custom eligibility rules. Learn more.
Note
It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.
Use the following commands to manage reviews:
@coderabbitai resume to resume automatic reviews.@coderabbitai review to trigger a single review.Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review.
Codex reset selection now evaluates usage windows against the current time. The adapter uses session reset data when available and published usage limits when no session snapshot exists. Session notifications can update a failed-turn error’s reset time.
Changes: Codex usage reset resolution
| Layer / File(s) | Summary |
|---|---|
Reset calculation and provider tests apps/server/src/provider/codexUsageLimits.ts, apps/server/src/provider/codexUsageLimits.test.ts | The calculation excludes windows whose reset time has passed. It selects windows at 100% usage, or windows at 99% or higher when none are at 100%. Tests cover selection at a supplied time. |
Failure reset resolution and session updates apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts | The adapter resolves reset times from session snapshots before published usage limits. It tracks the reset source and updates limited-turn errors when the reset value changes. |
Provider wiring and replay scenarios apps/server/src/provider/Drivers/CodexDriver.ts, apps/server/src/provider/Drivers/CodexManagedProvider.ts, apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.test.ts | Both provider drivers pass usage limits from the current snapshot. Replay tests cover near-full and published resets, stale published limits, and later error-item updates. |
Estimated code review effort: 3 (Moderate) | ~20 minutes
Change: Bug fix · Severity of issue fixed: Medium
Possibly related issues
resetAt when a new Codex session has no quota notification. This change resolves resets from published limits when session data is absent.resetAt on the first limited request. This change adds a published-limit fallback when no session snapshot exists.Suggested reviewers: shivamhwp, t3dotgg
35edcCodex usage-limit stops now keep their known reset time, so the resume and snooze actions stay available. No merge-blocking risk remains.
Security architecture risk: 🔵 Low · up to 98815
The change is narrowly scoped to reporting when Codex usage limits reset. No new permissions or cross-account access were identified. Combined interruption and recovery scenarios remain incompletely covered.
Retained concerns No architecture-level concerns identified.
Security Blast Radius
Trust Boundaries and Controls
Failed Failed checks: 1 inconclusive
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Linked Issues check | Inconclusive | [#14169] Session and published limit selection, expiry filtering, and regression tests address missing reset times. The terminal handler replaces event.failure.resetAt with the derived reset, even w… | Provide evidence of how Codex terminal usage-limit events obtain failure.resetAt, including whether it can be non-null before the terminal handler. |
| Check name | Status | Explanation |
|---|---|---|
| Title check | Passed | The title clearly describes the main change: preserving reset times for Codex usage-limit stops. |
| Description check | Passed | The description is mostly complete. It explains the problem, change, linked issue, verification, and agent use. It omits the template headings, and the supplied context does not confirm whether the li… |
| Out of Scope Changes check | Passed | [#14169] The adapter, provider wiring, reset-selection helper, and tests support usage-limit recovery. The model-bucket filter prevents an unrelated quota from supplying the main allowance reset. |
Explanation
The description is mostly complete. It explains the problem, change, linked issue, verification, and agent use. It omits the template headings, and the supplied context does not confirm whether the linked issue was triaged.
Explanation
[#14169] Session and published limit selection, expiry filtering, and regression tests address missing reset times. The terminal handler replaces event.failure.resetAt with the derived reset, even when the derived reset is null. The available evidence does not establish whether a Codex terminal usage-limit event can contain a known reset before this handler.
Resolution
Provide evidence of how Codex terminal usage-limit events obtain failure.resetAt, including whether it can be non-null before the terminal handler.
1bbdcfa5-8f00-4bd2-9bcf-c49950325335Reviewing files that changed from the base of the PR and between a8abab37b1fa17e4bfe0a264d761d7e826906567 and 35edccb9e754d1259b1d07c5d82d2e9311cc80ea.
apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.test.tsapps/server/src/orchestration-v2/Adapters/CodexAdapterV2.tsapps/server/src/provider/Drivers/CodexDriver.tsIncluded review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 8 remain after this review.
Hit this today on 0.0.46-nightly.20261015.3145 (macOS, ChatGPT Plus, Codex CLI 0.162.1), same as case 1.
The last codex update in my session log read primary: { usedPercent: 99, resetsAt: 1792065663 }, which is 14:01 CEST. The turn then failed with usage_limit_exceeded: "try again at 2:01 PM". The banner showed "Reset time unavailable; retry manually". Usage never reached 100 in that session; the peak was 99.
I wrote a smaller fix before finding this PR (fall back to the fullest window when none reads 100, skipped when a workspace credit/spend cap caused the stop) and ran it against the existing tests. The 99% case fails on main with expected null and passes with the change. Yours covers more, so I'm adding this as another repro rather than opening a second PR.
Additional Windows reproduction on T3 Code 0.0.46-nightly.20261015.3176, Codex 0.163.0, ChatGPT Plus. This matches the missing in-session snapshot path described here and in #14169.
A read-only inspection of the local state found a Codex root failure with:
| 1 | { |
| 2 | "class": "usage_limit", |
| 3 | "code": "usageLimitExceeded", |
| 4 | "resetAt": null |
| 5 | } |
The same failure's message ended with "try again at 5:24 AM", while the composer showed "Reset time unavailable; retry manually". After the allowance reset, Usage showed current countdowns and available capacity, while that chat retained its saved failure. The later usage panel does not establish the exact percentages at the original refusal.
Before finding this PR, we installed a small local workaround. Sharing it here rather than opening a competing PR:
limitedTurnItems, fork a same-client account/rateLimits/read request, bounded to three seconds.rateLimitsByLimitId.codex, otherwise accept the legacy snapshot only if its bucket is Codex or unspecified.turn_item.updated with the missing reset.One implementation detail: the lookup must be forked. The raw protocol reader awaits notification callbacks, so awaiting another RPC inline inside the terminal notification callback can prevent that reader from consuming its reply. Starting the lookup after the failed item is registered also avoids a reply arriving before the late-fill map contains the item.
This complements the discussion here; it is not a replacement for this PR's 99% handling. Our workaround still relies on the existing helper's exhausted-window rule, so a refreshed snapshot that only reports 99% can still leave the reset unknown.
Verification: nine isolated regression cases passed using T3's bundled Effect runtime and mocked usage responses: a session reset, both windows exhausted (later reset wins), multi-bucket selection, an already-reset allowance, a missing timestamp, an unrelated bucket, request failure, request timeout/nonblocking dispatch, and preserving an existing reset. The patched server passed the JavaScript syntax check and the desktop app restarted normally. We have not run this against a new real quota refusal, or run the repository's native adapter suite for this bundled workaround.
This is the tested bundled-code diff, not a source-ready PR or a request to commit generated files. The source location is apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts.
| 1 | --- a/apps/server/dist/binCli-BU_S3Cf-.mjs |
| 2 | +++ b/apps/server/dist/binCli-BU_S3Cf-.mjs |
| 3 | @@ -223198,7 +223198,7 @@ |
| 4 | turnItem: artifacts.turnItem |
| 5 | }); |
| 6 | }).pipe(orDie)); |
| 7 | - yield* client.handleServerNotification("account/rateLimits/updated", (payload) => gen$1(function* () { |
| 8 | + const applyT3ResetSnapshot = (payload) => gen$1(function* () { |
| 9 | yield* update$4(rateLimitSnapshot, (previous) => mergeCodexRateLimits(previous, payload.rateLimits)); |
| 10 | const resetAt = codexUsageLimitResetAt(yield* get$7(rateLimitSnapshot)); |
| 11 | for (const item of (yield* get$7(limitedTurnItems)).values()) { |
| 12 | @@ -223226,7 +223226,8 @@ |
| 13 | checkedAt |
| 14 | }); |
| 15 | } |
| 16 | - }).pipe(orDie)); |
| 17 | + }); |
| 18 | + yield* client.handleServerNotification("account/rateLimits/updated", (payload) => applyT3ResetSnapshot(payload).pipe(orDie)); |
| 19 | yield* client.handleServerNotification("thread/tokenUsage/updated", (payload) => gen$1(function* () { |
| 20 | accumulateCodexTurnTokenUsage(usageStateForThread(payload.threadId), payload.turnId, payload.tokenUsage); |
| 21 | const context = yield* awaitActiveTurn(payload.turnId); |
| 22 | @@ -224130,6 +224131,19 @@ |
| 23 | occurredAt: yield* now |
| 24 | }); |
| 25 | yield* update$4(limitedTurnItems, (items) => new Map(items).set(context.providerThread.id, item)); |
| 26 | + // Local T3 reset-time fix: refresh after saving the failed item. |
| 27 | + // Fork so the protocol reader remains free to receive the reply. |
| 28 | + yield* client.request("account/rateLimits/read", null).pipe( |
| 29 | + timeoutOption(millis(3000)), |
| 30 | + flatMap$1((response) => { |
| 31 | + if (!isSome(response)) return void_$1; |
| 32 | + const snapshot = response.value.rateLimitsByLimitId?.codex ?? response.value.rateLimits; |
| 33 | + if (!snapshot || snapshot.limitId && snapshot.limitId !== "codex") return void_$1; |
| 34 | + return applyT3ResetSnapshot({ rateLimits: snapshot }); |
| 35 | + }), |
| 36 | + catch_(() => void_$1), |
| 37 | + forkIn(scope) |
| 38 | + ); |
| 39 | } |
| 40 | }); |
| 41 | const emitOrDeferRootTerminal = fn("CodexAdapterV2.emitOrDeferRootTerminal")(function* (input) { |
Prepared with Codex (GPT-6) in the Codex desktop app.
Commenting on behalf of @jaikhuranna (posted by Claude Code). This adds another reproduction of case 1 and an end-to-end check of this PR in a real client.
Same refusal, different outcome, 3 seconds apart. On 2026-10-17, two Codex threads on the same account hit the limit 2.4 s apart. Codex sent both the same "try again at 7:12 AM" message:
last codex update before the refusal | stored failure.resetAt | client | |
|---|---|---|---|
| thread A (21:52:06.961Z) | primary: { usedPercent: 99, resetsAt: 1792287729 } | null | "The provider did not report a reset time. Retry manually" |
| thread B (21:52:09.350Z) | primary: { usedPercent: 100, resetsAt: 1792287729 } | 2026-10-18T01:42:09.000Z | "Usage limit resets 07:12:09", with Cancel auto-resume and Snooze until reset |
So the reset was already known for thread A. The >= 100 filter dropped it because the whole-percent update still read 99%.
End-to-end check. I wrapped the real codex app-server so only turn/start is faked. It answers with an account/rateLimits/updated at usedPercent: 99 (reset 4 h out), then turn/completed failed with codexErrorInfo: "usageLimitExceeded", the same sequence as thread A. It drops the real account's rate-limit notifications, so the 99% update is the only one T3 Code sees. I ran an isolated dev server (showcase data) with the Codex binary path pointed at the wrapper:
main @ 16918b57d6 | this PR cherry-picked onto the same main |
|---|---|
| main: Usage limit reached, Reset time unavailable; retry manually | This PR: Retry after 1:22 PM, banner with Resume at reset and Snooze until reset |
The reset shown (1:22:57 PM) matches the faked 99% window's resetsAt to the second, so the result comes from the near-full-window rule, not the published-limits fallback.
Rebasing onto current main. The cherry-pick has a single conflict, in CodexAdapterV2Options: main removed the doc comment above resolveRuntime, and this PR adds getUsageLimits next to it. With getUsageLimits kept and the comment dropped:
vp test run apps/server/src/provider/codexUsageLimits.test.ts apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.test.ts: 194 passedtsc-rs --noEmit in apps/server: no errors| 1 | #!/usr/bin/env node |
| 2 | // Wraps the real `codex app-server`, but answers every turn/start itself with a |
| 3 | // 99% usage update followed by a usageLimitExceeded refusal. |
| 4 | import { spawn } from "node:child_process"; |
| 5 | import { createInterface } from "node:readline"; |
| 6 | |
| 7 | const child = spawn(process.env.REAL_CODEX ?? "codex", process.argv.slice(2), { |
| 8 | stdio: ["pipe", "pipe", "inherit"], |
| 9 | }); |
| 10 | child.on("exit", (code) => process.exit(code ?? 0)); |
| 11 | const send = (frame) => process.stdout.write(`${JSON.stringify(frame)}\n`); |
| 12 | const now = () => Math.floor(Date.now() / 1000); |
| 13 | const turn = (id, status, error = null) => ({ |
| 14 | id, items: [], itemsView: "notLoaded", status, error, |
| 15 | startedAt: now(), completedAt: status === "inProgress" ? null : now(), durationMs: null, |
| 16 | }); |
| 17 | |
| 18 | let turns = 0; |
| 19 | createInterface({ input: process.stdin }).on("line", (line) => { |
| 20 | let frame; |
| 21 | try { frame = JSON.parse(line); } catch { child.stdin.write(`${line}\n`); return; } |
| 22 | if (frame.method !== "turn/start") { child.stdin.write(`${line}\n`); return; } |
| 23 | const threadId = frame.params.threadId; |
| 24 | const turnId = `proxy-limit-turn-${++turns}`; |
| 25 | const resetsAt = now() + 4 * 60 * 60; |
| 26 | send({ id: frame.id, result: { turn: turn(turnId, "inProgress") } }); |
| 27 | send({ method: "turn/started", params: { threadId, turn: turn(turnId, "inProgress") } }); |
| 28 | setTimeout(() => { |
| 29 | send({ method: "account/rateLimits/updated", params: { rateLimits: { |
| 30 | limitId: "codex", |
| 31 | primary: { usedPercent: 99, resetsAt, windowDurationMins: 300 }, |
| 32 | secondary: { usedPercent: 16, resetsAt: resetsAt + 6 * 86400, windowDurationMins: 10080 }, |
| 33 | } } }); |
| 34 | send({ method: "turn/completed", params: { threadId, turn: turn(turnId, "failed", { |
| 35 | message: "You've hit your usage limit. ... try again later.", |
| 36 | codexErrorInfo: "usageLimitExceeded", |
| 37 | }) } }); |
| 38 | }, 500); |
| 39 | }); |
| 40 | |
| 41 | // Drop the real account's rate-limit updates so only the 99% one reaches T3 Code. |
| 42 | createInterface({ input: child.stdout }).on("line", (line) => { |
| 43 | if (!line.includes('"account/rateLimits/updated"')) process.stdout.write(`${line}\n`); |
| 44 | }); |
Taking over this one as maintainer for batch codex-06. I will preserve the contributor history, merge current main, keep focused regression coverage, and verify session reset precedence before publishing. No merge is planned.
