[Bug] Main-account hard lock outlives an early reset redeemed outside opencodex until the old predicted reset #7312

Client or integration

Codex CLI

Area

Authentication and account pool

Summary

When the main account's usage is reset early, outside opencodex (a reset credit redeemed somewhere other than ocx account reset-credits), the main-account hard lock keeps refusing every native request locally until the previously predicted reset time, which can be days away. Nothing in the default configuration ever re-reads usage in that state, so the lock only clears when someone opens the dashboard or runs ocx account refresh openai.

Why it cannot notice the early reset:

1. While codexMainAccountHardLock blocks, requests are refused locally (5–140 ms, failureStage: headers-only), so no upstream response can carry fresh usage.
2. runMainAccountHardLockRecovery() returns before probing whenever the blocking window's reset is still in the future (src/codex/auth-api/pool-mode-gate.ts:104 on dev: "A predicted reset is a scheduling hint, never proof that the hard lock can be lifted."). This wait is intentional (fix(codex): pace quota recovery queries #6179) and covered by known reset waits locally, then verifies recovery instead of unlocking by time in tests/codex-integration/main-account-hard-lock-recovery.test.ts.
3. The only other periodic reader, src/quota/reset-poller.ts, does nothing unless quotaResetNotify is enabled, and it is disabled by default.
4. Redeeming through opencodex is fine: consumeResetCredits() calls refreshAfterManualReset() and publishes fresh usage. The gap is a reset that happens anywhere else (Codex App, web, or an upstream-side reset), which the "wait for the predicted reset" assumption does not cover.

So the design assumption "usage cannot drop before the known reset" no longer holds once reset credits exist, and the lock can outlive the real block by up to a weekly window.

Expected: an early reset should be noticed within a bounded time without user action. Some options, in order of how little they change:

• While blocked with a future reset, still allow the recovery sweep to read WHAM usage on a slow, capped cadence (for example every 30–60 minutes, reusing the existing nextQuotaQueryDelay / Retry-After pacing), instead of not at all until the reset.
• Or treat a non-zero resetCredits count on the main account as "an early reset is possible" and only then enable that slow probe.
• At minimum, surface it in the 429 message: the current text suggests waiting or disabling the lock, but not that ocx account refresh openai clears a stale block.

Reproduction

1. Use the main (native Codex login) account until the hard lock blocks (here, observed message: Codex main account is blocked by the main-account quota policy (5h ≥ 90%, weekly ≥ 98%)).
2. Redeem a reset credit outside opencodex (here, not via ocx account reset-credits; the ocx service log has no reset-credit call).
3. Send Codex CLI requests through opencodex: every native OpenAI model returns local 429 rate_limit_exceeded (observed for gpt-6-luna, gpt-5.6-luna, gpt-6.1-sol, gpt-6-astra, 59 of 59 recent native requests), while non-OpenAI providers keep returning 200.
4. Run ocx account refresh openai: it reports weekly 3%, and the next Codex CLI request returns 200 immediately.

I could not recover the exact pre-refresh cached quota tuple (the cache file was overwritten by the refresh), so which window was blocking and its stored reset time are not shown here.

Version

opencodex 2.83.0 (npm @bitkyc08/opencodex); the same code path is unchanged on dev as of 2026-10-17. Codex CLI 0.163.0.

Operating system

macOS (Darwin 25.5.0, arm64)

Provider and model

openai (native Codex main account, Pro plan) — gpt-6.1-sol, gpt-6-luna, gpt-5.6-luna, gpt-6-astra

Logs or error output

status: 429, durationMs: 14, errorCode: rate_limit_exceeded, failureStage: headers-only
upstreamError: Codex main account is blocked by the main-account quota policy (5h ≥ 90%, weekly ≥ 98%). Choose another account, wait for quota to reset, or disable codexMainAccountHardLock in Settings.
routeDecision.selected: { provider: openai, model: gpt-6-luna, reason: native-family }

After ocx account refresh openai:

main  pro  weekly 3%  resets 2026-10-24T22:01:09.000Z

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.