Triage

Confirmed on t3code/codex-turn-mapping at 30f213185 (current tip of that branch). Not a duplicate, and main does not have this recovery path.

The composer banner and Usage → Limits read different snapshots, and nothing copies one into the other.

The banner in UsageLimitRecoveryBanner uses only thread.runtime.usageLimitResetAt. That value is the latest root error item's failure.resetAt (threadErrorSummary). Codex sets it from the in-session rateLimitSnapshot in CodexAdapterV2, which starts empty and is filled only by account/rateLimits/updated. codexUsageLimitResetAt returns null unless every window at usedPercent >= 100 has a resetsAt. A notification that only names rateLimitReachedType, a 100% window with no resetsAt, or a non-codex limitId (those are ignored, including model-specific buckets) leaves resetAt null. The banner then shows "Reset time unavailable; retry manually" and hides Resume at reset / Snooze until reset. A later notification can backfill the turn item, but only when that notification itself produces a non-null reset.

Usage → Limits is the status probe in CodexProvider: account/rateLimits/read, mapped by codexRateLimitsToLimits, preferring rateLimitsByLimitId.codex. That result is what draws the Session countdown. It is never written into the adapter's rateLimitSnapshot. A probe that already has Session resetsAt therefore does not repair a turn that stopped without one. Weekly quota still remaining does not change this. Only exhausted windows are considered, and the probe windows are not consulted at all.

One correction: the stored sentence "Codex usage limit reached. Send the message again once the limit resets." is codexUsageLimitMessage's no-snapshot fallback. The adapter does not call that helper. It stores Codex's turn.error.message. The missing "resets in 4h 12m" clause is because that formatter is not on the turn path. The broken part is resetAt, which is what the banner and the auto-resume worker both require.

Same usageLimitResetAt field drives the mobile recovery card. Workaround is to retry manually once the Limits countdown reaches zero.

Here is what Space Bunny Free did (if it helps at all, if not just ignore this): # The core constraint

Everything hinges on one line in the orchestrator. Before my change it read:

This is an exact string match between the reset recorded on the turn's failure and the reset the client sends back. It exists for a real reason: if a limit moved between the moment we showed the user "resets at 3pm" and the moment they clicked, scheduling recovery against the stale value would wake a thread into a limit that's still active.

The consequence is that the client can never invent a reset. Any value it derived from the Usage page would differ from the recorded one and be rejected. That's exactly what the original code did, and exactly why the button rendered but always errored. So the reset has to be written onto the failure itself, and the client just echoes back what the server tells it.

Two layers, because there are two kinds of broken thread

New failures get fixed at the adapter, where the failure is constructed. CodexAdapterV2.ts:1625:

This sits after codexUsageLimitResetAt in the fallback chain at all three reset sites. The existing chain was already event.failure.resetAt ?? codexUsageLimitResetAt(...); I appended one more ??. The helper is read off snapshot.getSnapshot — the same published Limits snapshot the Usage page renders.

One detail worth flagging: snapshot is declared after the adapter is constructed, so the read is Effect.suspended (CodexDriver.ts:191). The pre-existing onUsageLimits was an arrow function, so it evaluated lazily and the ordering was fine; a bare .pipe() would have evaluated eagerly and thrown used before declaration. The comment records why.

Already-failed threads can't be fixed there — the failure is persisted, and the event log is immutable. So the sweep backfills them: UsageLimitRecoveryWorker.ts asks the projection for limit-blocked threads whose failure named no reset (ProjectionStore.ts:5755), takes the reset from the provider's published snapshot, and dispatches it. The orchestrator then records it by emitting a turn-item.updated carrying the filled failure.

That's why this is an appended event rather than a mutated row — the adapter's late-fill already does exactly this, so there's precedent, and the projection replays it like any other event.

The one safety change, and why it's narrow

Orchestrator.ts:2450:

Previously this was a single equality. Now a mismatch is acceptable in exactly one case: the failure recorded nothing at all.

The argument is that the check exists to invalidate a limit the user was shown. If no reset was ever recorded, nothing was shown, so there's nothing to invalidate. Every other guard still runs unchanged — it's still the latest failed run, still classified usage_limit, the reset must be in the future, thread not archived or settled, no pending runtime request. A failure that named a reset still demands an exact match, so a limit that moved under you still refuses.

I want to be explicit that this is the one place I loosened a safety check, and it's the reason the backfill persists the value rather than passing it through on every check: once recorded, it's the truth everything else compares against.

Why the fallback is conservative

usageLimitResetAtFromLimits (usageLimits.ts:505) only considers windows at usedPercent >= 100 that report a resetsAt, and picks the latest. So a resume is scheduled after every known exhausted window has reset. It over-waits rather than under-waits, and it declines to guess when no exhausted window names a reset. It also returns null on limits.unavailable, so a failed probe can't fabricate a recovery.

Two design choices I'd defend

I reverted the client fallback rather than fixing it. It was the wrong layer: no client-computed value can satisfy the invariant. Leaving it in would have meant shipping a button that always fails.

The SQL and in-memory projection paths are both implemented. ProjectionStore has layer (SQL, production) and layerMemory (tests), and getLimitRecoveryCandidates is duplicated across them. I mirrored that, using threadErrorSummary in the SQL path so both classify a thread identically — otherwise a thread could qualify for backfill in one path and not the other.

What I did not do

• codexUsageLimitMessage still omits the timing from its sentence, so the message won't name the reset even though the button now works. Cosmetic, but inconsistent.
• I didn't touch Claude, Grok, Cursor, or OpenCode. This is Codex-specific because Codex is the driver whose notification goes partial — the other adapters aren't affected by that particular gap.
• Nothing is verified in a real client. Every claim above is from tests and your event log.

Fresh repro on 0.0.46-nightly.20261003.2638 (orchestrator v2), 2026-10-04, instance codex_personal, model gpt-6-astra:

Three consecutive usage-limit stops on one thread (06:22:53Z, 06:25:25Z, 06:35:08Z) all stored:

The provider message stored on the same failure was:

You've hit your usage limit. Upgrade to Pro (https://chatgpt.com/explore/pro), visit https://chatgpt.com/codex/settings/usage to purchase more credits or try again at 6:01 AM.

The composer showed "Usage limit reached / Reset time unavailable; retry manually"; Resume at reset and Snooze until reset were absent. Two manual "Continue where you left off." retries (2:25 AM, 2:35 AM) stopped again, same loop as the original report.

So the reset existed in the provider message itself, and (per the original report) in the published Limits probe, while the in-session rateLimitSnapshot never supplied one.

One scoping question for #14889: the adapter fallback helps new stops, but these three failures are persisted with resetAt: null, so even after it lands this thread still cannot offer Resume at reset / auto-resume. Is the existing-failure backfill discussed in the comments meant as a follow-up, or is that out of scope? Worth deciding before the issue is closed, otherwise affected threads stay stuck until the next fresh limit stop.

(Also noting the other adapters — Grok, Cursor, OpenCode, Antigravity — don't populate resetAt on usage-limit failures at all today, so recovery is currently Codex (plus one Claude path) only.)

I'm hitting this too, but the cause in my logs is a bit different: the snapshot has a correct resetsAt, the window just never gets to 100.

T3 Code nightly 0.0.46-nightly.20261004, Linux, Codex app-server, ChatGPT Plus. This is the last account/rateLimits/updated before the turn that hit the limit:

The next turn fails with codexErrorInfo: "usageLimitExceeded" and "...or try again at 12:15 PM." 1791105349 is 12:15:49 local time, so the reset time was already in the snapshot. No other codex snapshot arrives after the failure. codexUsageLimitResetAt keeps only windows at usedPercent >= 100, gets an empty list and returns null, so the banner says "Reset time unavailable".

An older thread shows the same thing: primary at 99, rateLimitReachedType: null, resetsAt matching "try again at 8:09 PM". Every Codex usage_limit failure in my local state DB has resetAt: null. The Claude ones all have a reset time.

A third thread started while I was already limited and got no Codex snapshot before it failed. That case needs the Usage → Limits fallback you described. The 99% case could be fixed inside codexUsageLimitResetAt: when the turn has already failed with usageLimitExceeded and no window is at 100, take the window named by rateLimitReachedType, or else the window with the highest usedPercent that has a resetsAt. The failure already tells us a limit was hit, so 99 here is a rounded value, not remaining quota.

I can open a PR for that with a test for the 99% snapshot if that approach works for you.

Additional runtime evidence for the empty in-session snapshot path described in the triage above. The useful detail is a native initialization after the last normal quota update, followed by premium-only notifications before repeated failures.

Environment: macOS arm64, Orchestrator V2. Installed package: 0.0.46-nightly.20261013.3080. The backend process predates the installed archive's modification time, so its exact in-memory build is unconfirmed. Times below are UTC on October 14, 2026.

For the same configured Codex account, retained native logs show:

There was no intervening normal codex notification after that initialization in the retained log. Turns ending at 07:01:11.818, 07:04:02.175, and 07:14:07.014 all stored class: usage_limit, code: usageLimitExceeded, resetAt: null.

The raw Codex error had only message, codexErrorInfo, additionalDetails: null, and misalignment: null, with no structured reset field. Its message named Oct 20th, 2026 6:31 AM without a timezone. A separate account/rateLimits/read at 07:05:51Z returned an exhausted window with resetsAt: 1792503071, or 2026-10-20T13:31:11Z. That clock time is consistent with UTC-7. The separate read does not prove the running adapter possessed the snapshot.

The installed bundle and release-tag merge helper ignore premium updates. In that inspected code, these updates cannot overwrite an existing normal snapshot; if the snapshot starts undefined, they leave it undefined. The release adapter allocates that snapshot inside openSession. The running process's older or different code remains an alternative until its build is established. This sequence supports investigating the already-triaged missing-snapshot fallback without proving which path the live adapter took.

The linked fix proposal #14889 is closed without merging. This sequence may be useful regression coverage for a successor: initialize with no snapshot, receive only a premium notification, then fail on quota while the same account's published quota has a future reset. Also retain the previously raised distinction between new failures and backfilling already-persisted failures.

No controlled integration reproduction or missed reset deadline is claimed. Account identities, thread IDs, prompts, and tool contents are omitted.

Follow-up on the build caveat in my comment above: the running backend is confirmed as 0.0.46-nightly.20261013.3080. The updater downloaded it at 04:02:27Z, the bundle was written at 04:03:22-23Z, and the backend process started at 04:03:26Z. It still holds that app.asar open (same inode as on disk), and the archive's change time precedes the process start, so the later modification time was a stamped timestamp, not a rewrite. That running archive contains the non-codex merge guard and allocates the rate-limit snapshot inside openSession right after initialized. The older-code alternative is therefore ruled out. This is still not an end-to-end reproduction.

Same symptom on 0.0.46-nightly.20261014.3105 (Windows, desktop server, viewed from the mobile app). The Codex turn on gpt-6.1-sol was refused on its first request with usageLimitExceeded ("…try again at 1:54 PM"). The only account/rateLimits/updated before the refusal was limitId: "premium" with primary/secondary null and credits 0. The banner said "The provider did not report a reset time", while Usage → Limits showed the reset. This matches case 2 in #18721.

Triaged with Claude Code (claude-opus-5-5) via t3 triage.

Another reproduction on current Nightly. It also includes a case that neither the 99% nor the pre-notification fix in #18721 obviously covers.

Impact: auto-resume is unusable for me because of this. With resetAt: null the banner only offers "retry manually". Resume at reset and Snooze until reset are not available, so nothing wakes the thread at 8:11 PM. I have to remember the time from the Codex app and come back to retry by hand. This happens to me regularly, not just once. Every thread and subagent that hits the limit stays stuck until I resume it manually.

Environment

• T3 Code (Nightly) desktop 0.1.1-nightly.20261019.3360, orchestrator v2
• macOS 26.5.1 (25F80)
• Codex CLI 0.163.0, model gpt-6.1-sol (medium)
• ChatGPT Plus (plan_type: "plus" in the rollout)
• Time zone Europe/Berlin (CEST, UTC+2)

What I see At 16:30 CEST on 2026-10-21, the composer banner shows "Usage limit reached · Reset time unavailable; retry manually". The Codex app shows "Your rate limit resets on 8:11 PM" for the same account. Codex's own error text also contains the time:

At the same time, Usage → Limits for the same Codex account shows the reset correctly:

• Session: 0% left, ↻ 3h 34m at 16:36:56 CEST, which works out to ≈ 20:11 CEST
• Weekly: 83% left, ↻ 5d 17h

So the Limits probe knows the reset, but the composer recovery snapshot does not. Because of that, the thread is never armed for auto-resume. Earlier Codex limit stops on this machine (Oct 12 and Oct 14) did store a resetAt and armed autoResume: true, so it is specifically the missing resetAt that breaks it.

Five Codex sessions were refused between 14:27 and 14:31 UTC: a main thread plus three delegated subagents, and a new thread. All five stored resetAt: null.

Case A: new thread, first request refused (matches case 2 in #18721) The only rate-limit update before the refusal was the empty premium bucket:

Case B: long-running thread, the main window was at 100% with a known reset 1.9 s before the refusal From the Codex rollout of the main thread (excerpt):

The stored failure for that run is still resetAt: null. The follow-up run at 14:28:10Z (preceded by another premium/null update) shows the same thing. The subagent sessions show the same pattern: a premium update with null windows a few ms before each refusal.

So in this case the reset was not 99% and was not missing from the session. A codex window at exactly 100% with a future resets_at arrived ~2 s earlier. It looks as if the trailing premium (model-specific, all-null) update replaces or clears the main-allowance snapshot before the refusal is mapped. #18721 says "model-specific quota buckets cannot claim the main allowance". It may be worth adding a regression case where a null premium update arrives after a 100% codex update and before the refusal.

Caveat: these excerpts come from the Codex rollout JSONL (~/.codex/sessions/...), not from T3's own trace. I couldn't find the corresponding account/rateLimits/updated notifications in server.trace.ndjson, so I'm assuming the app-server emitted the same sequence.

Fallback suggestion: Codex's refusal message always includes try again at <time>. Parsing it, in the user's local time zone and rolled to the next occurrence, would give a reset time even when no window snapshot is usable.

Additional reproduction on 2026-10-23: the 99% snapshot case is visible in T3's decoded app-server protocol log, including a 100% → 99% update with the same reset. Adding evidence here rather than opening a duplicate.

What happened

On Android, the thread says “The provider did not report a reset time. Retry manually when your limit is available.” Resume at reset is absent, while Usage → Limits shows Session 0% left with a reset countdown and Weekly 57% left. In the same timeline, two intervening failures display a reset time, but the latest failure loses it again.

Version and environment

T3 server 0.1.2-nightly.20261022.3526, Ubuntu x86_64, Orchestrator V2, Codex app-server 0.163.0, ChatGPT Plus, model gpt-6.1-sol, reasoning high. Both server and Codex versions are confirmed by the incident's initialize handshake, rather than the CLI currently on PATH. Android app/OS versions were not collected.

Evidence

Times below are UTC on 2026-10-23. Sanitized decoded account/rateLimits/updated notifications and error:

09:34:23.423  codex    primary.usedPercent=100  resetsAt=1792753209
09:34:26.803  codex    primary.usedPercent=99   resetsAt=1792753209
09:34:27.010  premium  primary=null secondary=null
09:34:27.012  error    codexErrorInfo=usageLimitExceeded
09:34:56.594  codex    primary.usedPercent=99   resetsAt=1792753209
09:34:57.351  premium  primary=null secondary=null
09:34:58.224  premium  primary=null secondary=null
09:34:58.227  error    codexErrorInfo=usageLimitExceeded

Both 99% notifications also contain secondary.usedPercent=43 and rateLimitReachedType=null. The primary reset is 2026-10-23T11:00:09.000Z. The provider's error text says “try again at 11:00 AM”.

Four root error items persisted on the same parent thread:

Diagnosis

In the release helper, only windows with usedPercent >= 100 qualify. The 99% update therefore excludes a valid reset despite an explicit usage-limit refusal. The merge helper accepts the later 99% primary, while ignoring the premium bucket; this evidence does not support blaming premium updates for clearing the snapshot.

The separate Limits probe and the adapter's in-session snapshot are not joined. The mobile controls use the failure-derived reset, and the recovery worker rejects candidates without it. Thus Limits can show a reset while recovery remains unavailable. This supports the 99% path already described in this issue and addressed by the still-open #18721.

Observed sequence and expected behavior

Run Codex work with delegated tasks until quota is refused; inspect the parent recovery banner, compare Usage → Limits, then inspect the decoded quota notifications and persisted root failures. A near-exhausted snapshot with a future reset should remain usable after an explicit usage-limit failure, with appropriate freshness and account checks. A regression replay should include 100% → 99% with an unchanged reset, then a premium-only notification and refusal, plus later parent continuations triggered by delegated-task results.

Verification and workaround

Evidence comes from the user's screenshots, read-only database inspection, decoded T3 protocol logs, and source at release commit f054d1b. No forced quota exhaustion or controlled integration replay was run; the auto-resume preference and a missed scheduled deadline were not independently established. Resume manually after the reset. No live state or source patch was applied. Screenshots are transcribed above; private thread/project identifiers, paths, prompts and credentials are omitted.

Investigated and written by GPT-6.1-Sol through the Codex harness in T3 Code.

@juliusmarminge Is this still planned to land? Still hitting the 99% case on the 10-23 nightly.

Confirmed on stable 0.1.2 (Windows desktop), with a specific trigger

Environment: T3 Code desktop 0.1.2 stable (serverVersion 0.1.2), Windows 11 x64, Codex on a ChatGPT Plus plan.

What happened: after a Codex usageLimitExceeded, the composer banner shows "Usage limit reached / Reset time unavailable; retry manually".

Diagnosis: codexUsageLimitResetAt (apps/server/src/provider/codexUsageLimits.ts) only keeps windows with usedPercent >= 100. Codex rejected the turn while the last account/rateLimits/updated still reported the primary window at 99%, with a valid resetsAt. The snapshot had the correct reset time, but it was filtered out. An empty limitId: "premium" notification (primary: null) also arrived right before the error.

Provider event log sequence (UTC):

resetsAt=1792966221 = 22:10:21 UTC, which matches Codex's "11:10 PM" in local time.

Repro: use Codex until the 5h window limit is hit. The last account/rateLimits/updated before the rejection often reports 99% (rounded or lagging), and the banner then falls back to "unavailable".

Suggestion: when the turn fails with usageLimitExceeded, treat the fullest window (or any window with a future resetsAt) as exhausted instead of requiring >= 100.

The logic is unchanged on main today.

Comment prepared with Claude Code (claude-opus-5-5) via t3 triage.

New messages bypass the queue while Codex is out of quota

Following up on my earlier report: automatic resume became available on one thread, but I then hit this sequence on another:

1. Codex had already hit its usage limit. T3 knew the reset time, and automatic resume was enabled.
2. Before that reset, I sent a new message. I expected it to stay in the queue until quota was available.
3. T3 sent it to Codex immediately. It failed because the quota was still exhausted.
4. After that failure, T3 no longer had a reset time for the latest attempt, so automatic recovery was unavailable again.

Expected: keep the new message queued until reset and preserve automatic recovery. Actual: send immediately → hit the same limit → lose the reset time needed for recovery. Please confirm the intended queue behavior for this situation.

What the logs confirm

On October 23, 2026, the reset was saved as 22:41:51 UTC, with automatic resume enabled. At 21:35:09 UTC, a new user message went directly to starting, then running; it never entered queued. Two seconds later it failed with usageLimitExceeded and resetAt: null. Pressing Continue before reset repeated the failure. A separate delegated thread did resume automatically at 22:41:51; the affected parent was continued manually at 22:43:41.

Environment: T3 server 0.1.3-nightly.20261023.3592, Codex 0.164.0 (both verified in initialization logs), Ubuntu x86_64, ChatGPT Plus, gpt-6.1-sol, high reasoning. Submissions are recorded as creationSource: web; exact client/version unknown. Investigation used existing logs, read-only database inspection and release source. No local fix or controlled replay was performed.

Investigated and written by GPT-6.1-Sol through the Codex harness in T3 Code.

Additional evidence: Codex usageLimitExceeded error payload provides reset time in error.message while resetAt is stored as null

Environment:

• T3 Code Desktop v0.1.5 (macOS arm64), also observed on Linux worker (headless)
• Provider: Codex (gpt-6.1-sol, high reasoning)

What happened: When hitting the usage limit during a Codex turn, the composer recovery banner displayed:

Usage limit reached / Reset time unavailable; retry manually

The auto-resume / snooze actions were disabled because failure.resetAt was saved as null, even though the Codex server returned the exact reset timestamp in the turn error message.

Decoded provider event sequence (UTC):

1. account/rateLimits/updated:
   json

   1	{
   2	"rateLimits": {
   3	"limitId": "premium",
   4	"limitName": null,
   5	"normalModelSlug": null,
   6	"primary": null,
   7	"secondary": null,
   8	"credits": { "hasCredits": false, "unlimited": false, "balance": "0" },
   9	"individualLimit": null,
   10	"spendControlReached": null,
   11	"planType": null,
   12	"rateLimitReachedType": null
   13	}
   14	}

2. error:
   json

   1	{
   2	"error": {
   3	"message": "You’ve hit your usage limit. Upgrade to Pro (https://chatgpt.com/explore/pro), visit https://chatgpt.com/settings/usage to purchase more credits or try again at Oct 30th, 2026 12:31 AM.",
   4	"codexErrorInfo": "usageLimitExceeded",
   5	"additionalDetails": null,
   6	"misalignment": null
   7	},
   8	"willRetry": false
   9	}

3. turn/completed: failed with status failed.

Persisted SQLite failure record:

Diagnosis:

• CodexAdapterV2.ts sets resetAt solely via codexUsageLimitResetAt(Ref.get(rateLimitSnapshot)).
• When Codex emits account/rateLimits/updated with limitId: "premium" (where primary: null and secondary: null), or before full window details arrive, codexUsageLimitResetAt returns null.
• T3 Code currently does not parse the try again at <timestamp> string from error.message when handling usageLimitExceeded.
• Because failure.resetAt remains null, UsageLimitRecoveryBanner.tsx displays "Reset time unavailable; retry manually", preventing the user from scheduling auto-resume or snooze.
• Parsing try again at <timestamp> as a fallback when snapshot lacks an active window would recover the reset time directly from the provider's refusal message.

Confirmed on 0.1.8-nightly.20261107.4327 (macOS arm64, desktop, local server), Codex gpt-6.1-sol on ChatGPT Plus — with two new triggers.

What happened: A Codex thread hit usageLimitExceeded. failure.resetAt resolved correctly (2026-11-07T18:40:27Z) and limitRecovery armed (autoResume: true, snooze: true). Seven minutes later a delegated Claude subagent finished. Its completion message started a new Codex run immediately. That run failed on the limit with resetAt: null, and so did a manual /goal resume. The banner now shows "Reset time unavailable; retry manually", and auto-resume will never fire: the recovery sweep only checks the latest failed run, while limitRecovery.runId still points at the original one.

Diagnosis:

1. A finished subagent wakes a thread that is waiting on a limit. ProviderContinuationService.dispatchContinuation sends the delegated-completion message.dispatch with queue_after_active and never checks limitRecovery or the snooze. The new run is certain to fail, and it replaces the run that recovery was armed on. This is the server-side version of the "new messages bypass the queue" comment above.
2. The reset time is lost when the Codex app-server restarts. The Codex process was re-initialized when that run started (initialize → thread/resume at 17:08:26Z). The fresh rateLimitSnapshot only received {"limitId":"premium","primary":null,"secondary":null} before the error, so codexUsageLimitResetAt returned null. Before the restart, the limitId: "codex" snapshot had primary.usedPercent: 100, resetsAt: 1794076827. The error text still said "try again at Nov 8th, 2026 12:10 AM".

Repro:

1. A Codex thread (ChatGPT plan) delegates a task to a Claude subagent via delegate_task.
2. The Codex parent hits its usage limit while the subagent is still running. Recovery arms correctly.
3. The subagent finishes before the reset. Its completion message starts a parent run, which fails with resetAt: null.
4. The banner loses "Snooze until reset" and auto-resume never fires.

Suggested fixes (judgment, not verified):

• Hold delegated-completion (and other server-generated) dispatches while limitRecovery is armed and the reset time is still ahead.
• Carry the previous reset time forward when a new usage-limit failure has none.
• Seed the snapshot (account/rateLimits/read) after an app-server restart, or fall back to parsing the reset time from the error message.