[Bug]: Usage Limits shows Codex -32600 warnings for custom proxy providers without OpenAI auth

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Configure a Codex provider with a working CLIProxyAPI endpoint and a proxy API key supplied through ANTHROPIC_AUTH_TOKEN. Use launch arguments equivalent to:

-c model_providers.cliproxy.name="cliproxy"
-c model_providers.cliproxy.base_url="http://PROXY:8317/v1"
-c model_providers.cliproxy.env_key="ANTHROPIC_AUTH_TOKEN"
-c model_providers.cliproxy.wire_api="responses"
-c model_provider="cliproxy"

2. Do not add a direct ChatGPT subscription login to this Codex environment.
3. Open Usage > Limits in T3 Code. A warning appears for each affected environment.
4. Optionally configure a CLIProxyAPI usage source. Its quota cards can be populated while the separate Codex warnings remain.

Expected behavior

Direct Codex subscription usage should be classified as unsupported for a custom provider without a subscription account. Independently configured CLIProxyAPI usage-source data should remain visible. Genuine failures for subscription-authenticated accounts should remain actionable.

Actual behavior

Both the desktop client and app.t3.codes display:

Codex (via cliproxy): Codex could not read usage (JSON-RPC -32600).

This occurs for three connected environments, while CLIProxyAPI usage-source quota cards are populated.

Impact

Minor bug or occasional failure

Persistent misleading warnings in Usage > Limits. No model-request failure was established by this investigation.

Version or commit

T3 server 0.0.40 on two Linux Kubernetes instances; T3 server 0.0.41-nightly.20260910.1473 on a Debian 13 server.

Environment

Linux; Debian 13 on the standalone server; Node v24.20.0 on that server; Codex CLI 0.154.0; custom CLIProxyAPI provider using Responses API and an environment-variable API key. Seen in both desktop and hosted web clients. Exact desktop version was not collected.

Logs or stack traces

Directly reproduced against codex app-server with the provider overrides above, after initialize and initialized:

{"id":2,"method":"account/read","params":{"refreshToken":false}}
{"id":2,"result":{"account":null,"requiresOpenaiAuth":false}}
{"id":3,"method":"account/rateLimits/read","params":{}}
{"id":3,"error":{"code":-32600,"message":"codex account authentication required to read rate limits"}}

Code inspection of the installed nightly server bundle: the Codex provider probe calls account/rateLimits/read and maps failures through codexRateLimitsFailureMessage. The usageLimits mapping classifies account.type === "apiKey" as unsupported, but account === null with requiresOpenaiAuth === false falls through to probeFailed. This is a suspected missing classification, not a tested patch.

Screenshots, recordings, or supporting files

No attachments. The exact warning and protocol reproduction are included above.

Workaround

No warning-removal workaround was applied. Independently configured CLIProxyAPI usage-source quota cards remain available. No runtime patch or authentication changes were made.

Report investigated and filed by an OpenCode agent using codex/gpt-6-astra. This was not run through t3 triage.

Start in apps/server by tracing the usageLimits mapping and codexRateLimitsFailureMessage around the Codex account/rate-limits probe. Reproduce the account/read and account/rateLimits/read sequence with account null and requiresOpenaiAuth false, then verify that custom-provider warnings are classified as unsupported while authenticated failures remain actionable and CLIProxyAPI quota cards remain visible.