Redeeming a Codex reset credit leaves T3 stuck: Usage keeps showing exhausted limits and limit-held threads never resume

Start by tracing CodexDriver.consumeResetCredit, snapshot.refresh, and resolveUsageLimitsAfterProbe to see why fresh limits do not update usageLimits.checkedAt. Then inspect needsUsageRecovery and UsageLimitRecoveryWorker, including how linked environments learn about fresh usage readings. The fix is done when redemption displays current limits without a false error and limited threads resume after an early reset, including on linked environments.

What happened

I hit the Codex weekly limit and redeemed a reset credit from Usage → Limits in the desktop app. Codex reset the account, but T3 behaved as if nothing happened:

1. The redeem action failed with "The reset was applied, but Codex could not confirm the new limits. Refresh to check."
2. Afterwards the Codex tile kept showing Session 0% left and Weekly 0% left, resetting in "4d 13h" (the old weekly reset), with 1 credit left. It kept showing that for at least 20 minutes and showed fresh values by the next morning, after the linked server had rebooted overnight.
3. A Codex thread stopped by the limit, on a linked environment with the same account, never resumed, and a message queued in it stayed held. It only ran again after I typed "Continue" by hand.

So from the UI the reset looked like it did not work, though Codex had applied it.

Diagnosis

Codex side worked. account/rateLimitResetCredit/consume returned reset; afterwards account/rateLimits/read on both machines returns usedPercent: 0 for both windows, the weekly resetsAt restarts from the redemption, and availableCount dropped by one.

False error and stale tile. After redeeming, CodexDriver.consumeResetCredit calls snapshot.refresh. That refresh completed account/rateLimits/read in 523 ms and checkCodexProviderStatus succeeded, yet usageLimits.checkedAt did not move, so it threw "could not confirm". Per resolveUsageLimitsAfterProbe, either the probe yielded no usable limits (probeFailed republishes the old snapshot) or the published checkedAt won; the read failure is logged only at debug level, so the trace cannot tell. The republished snapshot is not unavailable, so needsUsageRecovery stays false and nothing re-probes soon.

Threads not resuming is #22307: limitRecovery.resetAt still said 2026-11-14 and UsageLimitRecoveryWorker waits for that deadline. New here: the redemption ran on the desktop's local environment while the limited thread lived on a linked one with the same account, so dispatching only from the redeem action would miss it; a check driven by fresh usage readings (#24511) would cover it.

References are against main 45e0143c.

Steps to reproduce

1. Use a ChatGPT-plan Codex account until the weekly limit is hit, with a reset credit available, and have a Codex thread stopped by the limit (ideally on a second, linked environment with the same account).
2. In the desktop app, redeem the Codex reset in Usage → Limits.
3. See the "could not confirm" error, the tile still at 0% left with the old reset time, and the limited thread not resuming.
4. account/rateLimits/read from codex app-server reports 0% used.

Version

0.1.8-nightly.20261109.4433 (desktop app and its local server); linked environment server 0.1.8-nightly.20261108.4367

Environment

Linux (Arch) desktop app; linked Debian 13 server environment, same Codex account. codex-cli 0.167.0, Plus plan.

Evidence

# 2026-11-09 UTC
23:05     linked env: follow-up queued behind an active run
23:20     linked env: usageLimitExceeded, limitRecovery.resetAt 2026-11-14T13:45:21Z, queued run queueHeld true
23:35:05  desktop: consumeResetCredit -> consume Success (3485 ms)
23:35:09  account/rateLimits/read Success (523 ms), checkCodexProviderStatus Success
23:35:10  consumeResetCredit Failure: "The reset was applied, but Codex could not confirm the new limits."
23:48     linked env: manual "Continue" -> runs; 23:05 message still held

# account/rateLimits/read afterwards, both machines
primary usedPercent 0 (300 min), secondary usedPercent 0 (10080 min, resetsAt +7d), availableCount 1

Screenshot of the Usage → Limits tile to follow.

Related issues

#22307 and its fix #24511 (thread recovery ignores early resets), #26037 (held queue). #23054 is about duplicate per-environment tiles, not stale values.

Fix applied or workaround

Send "Continue" by hand in each limited thread. The tile showed fresh values the next morning after a reboot; I did not find a way to refresh it sooner from the app.

Filed by

Claude (Opus 5.5) in Claude Code, following the T3 triage playbook.