[bug] `codex-multi-auth check` no longer works due to using GPT-5-Codex for quota fetching?

[alphanin9]

Summary

codex-multi-auth check fails with the following:

Reproduction

$ codex-multi-auth check | sed -r 's/^(.*? |)[^@]+@[^ ]+/\1xxx@xxx.xxx/g'
Checking 2 account(s) with quick check + live check...
Model probe: gpt-5.3-codex | prompt family gpt-5-codex | tool search no | computer use no
  ✓ Account 1 (Personal (role:owner) [id:f73jsi], xxx@xxx.xxx id:f73jsi) | signed in and working (live check failed: {"detail":"The 'gpt-5-codex' model is not supported when using Codex with a ChatGPT account."})
  ✓ Account 2 (Personal (role:owner) [id:AA0Xbn], xxx@xxx.xxx id:AA0Xbn) | signed in and working (live check failed: {"detail":"The 'gpt-5-codex' model is not supported when using Codex with a ChatGPT account."})

Result: 2 working | 0 need re-login | 2 warnings

Expected Behavior

The account usage is fetched.

Actual Behavior

I get an error.

Environment

• codex --version: 0.133.0
• npm ls -g codex-multi-auth: /usr/local/lib└── codex-multi-auth@2.1.12
• OS: Fedora 44
• Node.js: v22.22.2

Compliance Confirmation

• [ x ] I am using this project for personal development workflows.
• [ x ] This report does not request policy bypasses or prohibited usage.
• [ x ] I removed any secrets/tokens from this report.

[coderabbitai]

Coding Plan

Summary

• root cause is getUnsupportedCodexModelInfo only checks errorBody.error.message, missing the {"detail": "..."} format the api now returns
• fix detection to also check errorBody.detail for the unsupported pattern, enabling proper model fallback
• improve downstream messaging to distinguish "codex unavailable" from generic probe failures
• no changes to model fallback lists or probe endpoint selection—the current models are correct, detection was broken

Design Choices

Design Choice 1: api response format has changed from `{"error": {"message": "..."}}` to `{"detail": "..."}`

Options Considered:

1. extend getUnsupportedCodexModelInfo to also check errorBody.detail for the unsupported pattern
2. add a wrapper that normalizes response format before calling existing detection
3. change quota-probe to pre-process responses into a canonical format

Chosen Option: 1

Rationale: option 1: minimal change, keeps detection logic centralized in one function, follows existing pattern of checking multiple fields.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Fix Unsupported Model Detection for detail Response Format

this phase addresses the root cause: the api now returns {"detail": "..."} instead of {"error": {"message": "..."}}, causing detection to fail and raw json to leak into error output.

Task 1: Extend `getUnsupportedCodexModelInfo` to handle `detail` field

add fallback detection for errorBody.detail when errorBody.error is missing or not a record.

• in lib/request/fetch-helpers.ts:201-236, after the early return for !isRecord(maybeError), add logic to check errorBody.detail as a string
• test CHATGPT_CODEX_UNSUPPORTED_MODEL_PATTERN against errorBody.detail if present
• populate unsupportedInfo.message from errorBody.detail when matched
• this ensures the sequential fallback in lib/quota-probe.ts:396-418 correctly continues to the next model instead of throwing immediately

Task 2: Add regression tests for `detail` response format

verify the detection works with both response formats.

• add test cases in test/fetch-helpers.test.ts (or create if missing) for getUnsupportedCodexModelInfo with {"detail": "...model is not supported..."} input
• add test case in test/quota-probe.test.ts verifying fallback behavior when api returns {"detail": "..."} format
• flag: ensure tests cover the edge case where errorBody.error exists but is not a record (e.g., {"error": null, "detail": "..."})

🤖 Prompt for AI agents

this phase fixes the root cause in `lib/request/fetch-helpers.ts:201-236` where
`getUnsupportedCodexModelInfo` misses the `{"detail": "..."}` api response
format, causing raw json to leak into error output.

- in `lib/request/fetch-helpers.ts:201-236`, locate the block that checks
`errorBody.error.message` against `CHATGPT_CODEX_UNSUPPORTED_MODEL_PATTERN`
- after the early return for `!isRecord(maybeError)`, add a fallback branch
that:
  - checks if `errorBody.detail` is a string
  - tests `CHATGPT_CODEX_UNSUPPORTED_MODEL_PATTERN` against `errorBody.detail`
  - populates `unsupportedInfo.message` from `errorBody.detail` when matched
- this fix ensures `lib/quota-probe.ts:396-418` correctly `continue`s to the
next model in the fallback loop instead of throwing immediately

add regression tests:
- in `test/fetch-helpers.test.ts` (create if missing), add test cases for
`getUnsupportedCodexModelInfo` with `{"detail": "...model is not supported..."}`
input
- in `test/quota-probe.test.ts`, add a test verifying fallback behavior when the
api returns the `{"detail": "..."}` format
- flag: include edge case coverage for `{"error": null, "detail": "..."}` —
where `errorBody.error` exists but is not a record

Phase 2: Improve Messaging for Codex-Unavailable Accounts

this phase improves ux when all probe models fail due to account entitlement, distinguishing "codex unavailable" from generic probe failures.

Task 1: Create distinct error type for all-models-unsupported scenario

allow callers to distinguish "account doesn't have codex" from "probe network/auth failure".

• in lib/quota-probe.ts, after the model loop exhausts all options with unsupported errors, throw a specific error (e.g., CodexUnavailableError class or error with a detectable property like error.code = "codex_unavailable")
• track whether all failures were unsupported-model errors vs mixed failures
• only throw the distinct error when ALL models failed due to unsupported, not when there were other error types

Task 2: Handle codex-unavailable gracefully in `runHealthCheck`

display a clearer message for accounts without codex access.

• in lib/codex-manager.ts:2268-2274 (and mirrored block at 2364-2370), detect the codex-unavailable error type
• format message as "signed in and working (codex not available for this account)" instead of "live check failed: ..."
• consider whether this should increment warnings or use a separate counter—currently warnings is appropriate since the account is functional but limited
• flag: this changes user-visible output; ensure no downstream tooling parses the exact string "live check failed"

Task 3: Add tests for codex-unavailable messaging

verify the improved ux in health check output.

• add test in test/codex-manager-check-command.test.ts or integration tests verifying the message format when probe returns codex-unavailable
• mock fetchCodexQuotaSnapshot to throw the new error type
• verify warning count behavior

🤖 Prompt for AI agents

this phase introduces a distinct error type for all-models-unsupported and wires
it into `runHealthCheck` for cleaner ux output.

in `lib/quota-probe.ts`:
- after the model fallback loop exhausts all models in
`lib/quota-probe.ts:396-418`, check whether every failure was an
unsupported-model error
- track failures per-iteration: if ALL models failed due to `isUnsupported:
true`, throw a distinct error — either a `CodexUnavailableError` class or a
plain error with `error.code = "codex_unavailable"`
- only throw this distinct type when ALL models were unsupported; mixed failure
types should propagate the existing error behavior

in `lib/codex-manager.ts:2268-2274` and the mirrored block at `2364-2370`:
- detect the new codex-unavailable error type
- display `"signed in and working (codex not available for this account)"`
instead of `"live check failed: ..."`
- increment `warnings` (not a new counter) since the account is functional but
limited
- flag: this changes user-visible output — verify no downstream tooling or tests
assert on the exact string `"live check failed"`

add tests:
- in `test/codex-manager-check-command.test.ts`, add tests verifying the message
format when probe returns the codex-unavailable error type
- mock `fetchCodexQuotaSnapshot` to throw the new error type
- assert warning count increments correctly
- flag: missing regression tests here are a gap — ensure concurrency edge cases
are covered if `runHealthCheck` is ever called in parallel

Research

codex-multi-auth uses a sequential model fallback strategy for quota probing: lib/quota-probe.ts:23 defines DEFAULT_QUOTA_PROBE_MODELS = ["gpt-5.3-codex", "gpt-5.2-codex", "gpt-5-codex"]. when probing fails, getUnsupportedCodexModelInfo in lib/request/fetch-helpers.ts:201-236 detects model-unsupported errors by checking errorBody.error.message against CHATGPT_CODEX_UNSUPPORTED_MODEL_PATTERN. the check command wires through lib/codex-manager/commands/check.ts → runHealthCheck in lib/codex-manager.ts:2183.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

this phase fixes the root cause in `lib/request/fetch-helpers.ts:201-236` where
`getUnsupportedCodexModelInfo` misses the `{"detail": "..."}` api response
format, causing raw json to leak into error output.

- in `lib/request/fetch-helpers.ts:201-236`, locate the block that checks
`errorBody.error.message` against `CHATGPT_CODEX_UNSUPPORTED_MODEL_PATTERN`
- after the early return for `!isRecord(maybeError)`, add a fallback branch
that:
  - checks if `errorBody.detail` is a string
  - tests `CHATGPT_CODEX_UNSUPPORTED_MODEL_PATTERN` against `errorBody.detail`
  - populates `unsupportedInfo.message` from `errorBody.detail` when matched
- this fix ensures `lib/quota-probe.ts:396-418` correctly `continue`s to the
next model in the fallback loop instead of throwing immediately

add regression tests:
- in `test/fetch-helpers.test.ts` (create if missing), add test cases for
`getUnsupportedCodexModelInfo` with `{"detail": "...model is not supported..."}`
input
- in `test/quota-probe.test.ts`, add a test verifying fallback behavior when the
api returns the `{"detail": "..."}` format
- flag: include edge case coverage for `{"error": null, "detail": "..."}` —
where `errorBody.error` exists but is not a record
===============================================================================

Task: 2

this phase introduces a distinct error type for all-models-unsupported and wires
it into `runHealthCheck` for cleaner ux output.

in `lib/quota-probe.ts`:
- after the model fallback loop exhausts all models in
`lib/quota-probe.ts:396-418`, check whether every failure was an
unsupported-model error
- track failures per-iteration: if ALL models failed due to `isUnsupported:
true`, throw a distinct error — either a `CodexUnavailableError` class or a
plain error with `error.code = "codex_unavailable"`
- only throw this distinct type when ALL models were unsupported; mixed failure
types should propagate the existing error behavior

in `lib/codex-manager.ts:2268-2274` and the mirrored block at `2364-2370`:
- detect the new codex-unavailable error type
- display `"signed in and working (codex not available for this account)"`
instead of `"live check failed: ..."`
- increment `warnings` (not a new counter) since the account is functional but
limited
- flag: this changes user-visible output — verify no downstream tooling or tests
assert on the exact string `"live check failed"`

add tests:
- in `test/codex-manager-check-command.test.ts`, add tests verifying the message
format when probe returns the codex-unavailable error type
- mock `fetchCodexQuotaSnapshot` to throw the new error type
- assert warning count increments correctly
- flag: missing regression tests here are a gap — ensure concurrency edge cases
are covered if `runHealthCheck` is ever called in parallel

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[alphanin9]

For what it's worth this is still broken on the new release, reporting I have no access to Codex on the accounts despite both having Plus subscription.