Paused Codex accounts should not consume quota through caller-credential fallback #3647

Summary

My expectation is explicit: after I pause an account, OpenCodex should stop sending new quota-consuming requests using that account. This should apply to ordinary tasks, subagents, and automatic retries/fallbacks, not only to normal Pool selection.

In OpenCodex 2.42.0, source inspection found a caller-credential fallback path that appears able to use the paused main account when no Pool account can be selected. Please make account pause an effective exclusion for matching outgoing account credentials, including this fallback.

Environment

• OpenCodex: @bitkyc08/opencodex 2.42.0
• macOS, Codex desktop integration
• Canonical openai provider, Pool mode
• Quota strategy, auto-switch threshold 80%
• Main account __main__ paused; a secondary Pool account active

Source evidence

Inspected the source shipped in the installed 2.42.0 npm package.

In src/codex/auth-api.ts, the pause handler correctly sets pause state, clears the account's thread bindings, and reconciles the active account. Ordinary Pool selection also excludes paused accounts.

However, in src/codex/auth-context.ts, resolveCodexAuthContext contains this branch when selection returns no account:

if (!selected) {
  if (
    requestScopedMainCredential
    && fixedAccountId === undefined
    && options.excludeAccountId !== MAIN_CODEX_ACCOUNT_ID
  ) {
    return await resolveCallerOwnedMainContext();
  }
  // ...
}

This branch does not check isCodexAccountPaused(config, MAIN_CODEX_ACCOUNT_ID). The caller-owned context can return { kind: "main", accountId: null }, and authentication materialization preserves the caller's credential. When that credential belongs to the paused main account, the request appears able to consume its quota despite the pause.

Native subagent requests also reach the shared final authentication resolver in src/server/responses/core.ts; the concern is therefore not specific to subagents.

Evidence boundary

This is a source-supported routing concern, not an end-to-end reproduction or proof of unexpected billing.

I initially noticed apparent main-account quota movement around pausing. During the subsequent brief observation, main weekly usage stayed unchanged at the displayed percentage precision, while the secondary account's usage increased. Recent attributed requests used the secondary account. Those observations do not establish that the fallback caused the original apparent movement.

No live all-accounts-unavailable reproduction was performed.

Suggested minimal regression case — not yet executed

1. Configure Pool mode and pause __main__.
2. Make all other Pool accounts unavailable for the requested model.
3. Supply a valid forwardable caller credential belonging to the paused main account.
4. Submit an ordinary native request and a native subagent request.
5. Exercise the bounded retry path after a stored Pool account is rejected.

Expected: no new upstream model request is sent using the paused account. Return a clear unavailable/paused-account error if no permitted account remains.

Please distinguish a caller credential that matches the paused account from an unrelated caller identity; this should not indiscriminately block other accounts.

Expected behavior

• Pause excludes the account from new quota-consuming dispatches through OpenCodex, including fallback/retry paths and subagents.
• Changing rotation strategy or restarting Codex should not be necessary to enforce the pause.
• The same account should not become usable merely because its credential arrives from the client rather than the stored Pool.
• If a request was already dispatched before pause and cannot be cancelled, make that limitation explicit. It must not authorize subsequent requests or retries on that account.
• Quota/status refresh can remain available.

Related work

• fix(codex): retain caller main after pool rejection #3135 describes the deliberate bounded caller-main fallback after Pool rejection. The requested change is for explicit pause state to take precedence when that caller credential matches the paused account.
• feat(codex): add window-aware 99% main-account hard lock #3552 adds a 99% main-account hard lock. This request concerns manual pause at any usage level, not only a threshold-based lock.

I searched related issues and PRs and did not find an exact issue for this pause/fallback interaction. No credentials, account emails, prompts, or private logs are included.