fix(server): Codex behind a custom model provider no longer reports a usage error#33312
Summary
When Codex runs against a custom model provider (for example a [model_providers.*] entry with a bearer token, no codex login), account/read returns account: null with requiresOpenaiAuth: false. T3 still sent account/rateLimits/read, Codex rejected it, and the Usage page listed one error line per such instance and environment: Codex could not read usage (JSON-RPC -32600).
Such an instance has no subscription limits, like an API-key account. The probe now skips the rate-limit read when there is no account, and the status marks the limits unsupported. The Usage page already hides unsupported instances from its error list.
| 1 | probeCodexAppServerProvider |
| 2 | account/read |
| 3 | - account/rateLimits/read unless skipNativeUsage |
| 4 | + account/rateLimits/read unless skipNativeUsage or no account |
| 5 | |
| 6 | checkCodexProviderStatus |
| 7 | - apiKey account -> unsupported |
| 8 | + apiKey account, or no account and |
| 9 | + requiresOpenaiAuth false -> unsupported |
An account that is missing while requiresOpenaiAuth is true still reports Codex CLI is not authenticated as before.
Evidence
Runtime, Codex CLI 0.167.0 with a custom provider and no auth.json:
| 1 | account/read -> {"account":null,"requiresOpenaiAuth":false,"workspaceRouting":null} |
| 2 | account/rateLimits/read -> {"error":{"code":-32600,"message":"codex account authentication required to read rate limits"}} |
- Before: the extended case in
ProviderRegistry.test.ts("returns ready with unknown auth when app-server does not require OpenAI auth") failed onorigin/main2b65ffb641:usageLimits.unavailablewasprobeFailed, notunsupported. - After:
vp test run apps/server/src/provider/ProviderRegistry.test.ts apps/server/src/provider/CodexProvider.test.ts: 60 passed.vp run check:changed: format, lint, knip, graphql, typecheck (3 packages) and tests (62) pass. - Not checked: a desktop build with this change. The error lines were observed in the installed Nightly
0.1.8-nightly.20261109.4399.
Merge risk
Only Codex instances without an account change. They lose a request that always failed and an error line on the Usage page. ChatGPT, API-key and managed-auth instances are unaffected.
Written with Claude Opus 5.5 in Claude Code (via T3 Code).
Checks
Failing1
- CodeRabbitGitHubCancelled
Added 1 commit
- fix(server): Codex behind a custom model provider no longer reports a usage error432dca1
Approvability
Verdict: Approved at 432dca1
Macroscope's review found this PR approvable — Custom Codex providers without an OpenAI account now skip an unsupported usage query and report usage as unavailable rather than failed. The change is confined to usage-status discovery and reporting, without changing authentication or model selection.
You can add or adjust custom eligibility rules. Learn more.
Thanks, lukasbxy, for the fix and reproduction. This duplicates #22771 by juliusmarminge, which addresses the same custom-provider usage warning with broader regression coverage. Please follow that PR for the fix.
Reopening this as the more current fix for the same warning; thanks, lukasbxy. Please preserve successful native usage reads when account/read returns no account: that response can still be followed by valid limits. The narrower refusal handling and regression case in #22771 may help.
Note
🤖 GPT-6.1 Sol responding on behalf of saphid
Verified an additional error variant on two Linux x64 environments with Codex CLI 0.166.0. A custom Responses provider uses requires_openai_auth = false and an API key supplied through its configured environment variable. One environment runs T3 0.1.8-nightly.20261109.4433.
Read-only app-server probes through each configured launcher returned:
| 1 | account/read → account: null, requiresOpenaiAuth: false |
| 2 | config/read → model_provider: cliproxy, requires_openai_auth: false |
| 3 | account/rateLimits/read → JSON-RPC -32603 |
| 4 | failed to fetch codex rate limits: HTTP 401 Unauthorized |
| 5 | error.code: invalid_jwt |
| 6 | error.message: Could not find the appropriate key in your |
| 7 | authentication token. Please try signing in again. |
Both instances produce the Usage warning despite having no required OpenAI login. This differs from the -32600 authentication refusal in the PR description. Any narrower refusal handling requested above should cover this observed 401 invalid_jwt variant too, while preserving successful quota reads and genuine probe failures.
The native read is separate from the configured CLIProxyAPI usage source. No credential changes, installed-runtime patches, service restarts, or model turns were performed during this reproduction. The candidate PR was inspected, but not built or run locally. Following this existing fix rather than submitting a duplicate.
Thanks, lukasbxy, for the fix and reproduction. This addresses the same usage warning as #33739 by nuuls, which has broader live evidence and preserves successful accountless usage reads. Please follow that PR for the fix.