[danielyc]

Problem

When Codex is configured with a custom model_provider that needs no sign-in (e.g. a local OpenAI-compatible proxy), the Usage → Limits page shows a warning such as <environment> · Codex: Codex could not read usage (JSON-RPC -32600).

In that setup account/read returns { account: null, requiresOpenaiAuth: false }. Codex has no account rate limits to report, so account/rateLimits/read is refused with -32600 "codex account authentication required to read rate limits". T3 Code treated that expected refusal as a failed probe (probeFailed) and surfaced it as an error.

Change

checkCodexProviderStatus now marks usage limits as unsupported when there is no account and the app-server does not require OpenAI auth. This matches the existing handling for API-key accounts, which also have no account limits. Signed-out CLIs (requiresOpenaiAuth: true) are unchanged and still report the codex login message.

Scope and approval

This is a very small, focused fix for an obvious bug: an expected protocol response for a supported configuration (custom model providers) is shown to users as an error. It extends the existing apiKey → unsupported branch by one condition in one file and changes no product behavior beyond removing the false warning, so it qualifies without a prior issue or discussion.

Verification

• Reproduced on a Linux host (codex-cli 0.165.0) where ~/.codex/config.toml sets model_provider to a custom provider and there is no auth.json. Sending the probe's requests to codex app-server directly returned:
  • account/read → {"account":null,"requiresOpenaiAuth":false,...}
  • account/rateLimits/read → {"error":{"code":-32600,"message":"codex account authentication required to read rate limits"}}
• Extended the existing returns ready with unknown auth when app-server does not require OpenAI auth test in ProviderRegistry.test.ts. It feeds that rate-limit failure and asserts usageLimits.unavailable is { reason: "unsupported" }. It fails without the change (probeFailed) and passes with it.
• vp test run src/provider/ProviderRegistry.test.ts (39 passed) and the server typecheck pass.
• The Limits-page notice is built by collectLimitNotices (packages/shared/src/usageLimits.ts), which skips providers whose usage is unsupported, so the warning no longer appears.
• Not checked: the Usage page in a rebuilt desktop app.

Written with Claude Opus 5.5 in Claude Code (T3 Code).

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 4c27da0

Macroscope's review found this PR approvable — Custom Codex providers that require no OpenAI sign-in now report usage limits as unsupported instead of a probe error. The change is limited to status reporting and leaves authentication and provider execution unchanged.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

Walkthrough

Codex usage limits are now marked unsupported when the account is an API key or when no account exists and OpenAI authentication is not required. A registry test checks the no-account case when rate-limit reading fails.

Changes: Codex Usage Limits

Layer / File(s)	Summary
Unsupported usage case apps/server/src/provider/CodexProvider.ts, apps/server/src/provider/ProviderRegistry.test.ts	The provider returns usage limits with reason "unsupported" when no account exists and OpenAI authentication is not required. The test checks this result when rate-limit reading fails.

Priority: Normal

Estimated code review effort: 2 (Simple) | ~5 minutes

Change: Bug fix

Possibly related issues

• pingdotgg/t3code issue 11873 reports the same no-account response and rate-limit read failure that this change classifies as unsupported.

Possibly related PRs

• pingdotgg/t3code#23781: Changes usage probing for the same requiresOpenaiAuth: false account shape.
• pingdotgg/t3code#22296: Changes the same usage-limit branch and adds a test for the same account shape.

Suggested reviewers: juliusmarminge

Merge Risk: Minimal · up to 4c27d

The intended Codex unsupported-usage behavior is covered and no merge-blocking risk remains.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the change: Codex custom providers no longer show a usage error. This matches the main change, which marks Codex usage limits as unsupported when no account exists and OpenAI auth is n…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Description check		The pull request includes all required sections: Problem, Change, Scope and approval, and Verification. It explains the expected behavior, implementation, scope rationale, reproduction details, focuse…

Full details: Title check

Explanation

The title names the change: Codex custom providers no longer show a usage error. This matches the main change, which marks Codex usage limits as unsupported when no account exists and OpenAI auth is not required. The title follows the conventional commit form and is 64 characters long.

Full details: Description check

Explanation

The pull request includes all required sections: Problem, Change, Scope and approval, and Verification. It explains the expected behavior, implementation, scope rationale, reproduction details, focused test coverage, reported results, and an unchecked limitation.

Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[danielyc]

Closing as a duplicate of #18622, which a maintainer has taken over and which also covers this case (custom Codex provider, no login: account/read returns { account: null, requiresOpenaiAuth: false } and account/rateLimits/read fails with -32600). Tracking issue: #11873.