[Bug]: A Codex turn retrying HTTP 429 sleeps as Working for hours instead of showing Limited #28936

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

Summary

A provider can answer Codex with 429 and a Retry-After but without OpenAI's usage_limit_reached body. CLIProxyAPI does this once every account behind it is out of quota (model_cooldown). Codex 0.166 then retries and sleeps until Retry-After, with no cap. T3 shows the turn as Working with "Retrying provider (1/5)" for the whole sleep: hours, or days for a weekly window. It never shows Limited. The retry is recorded as a transport error, although T3 already treats the same 429 as a usage limit once retries are exhausted (#16288, #17501).

Steps to reproduce

1. Point a Codex provider instance at a Responses endpoint that answers every POST /v1/responses with 429, Retry-After: 10800 and a body without error.type: "usage_limit_reached", for example {"error":{"code":"model_cooldown","message":"All credentials for model gpt-6-astra are cooling down"}}. A CLIProxyAPI instance whose Codex credentials are all out of quota answers this way.
2. Start a Codex thread and send any message.
3. Watch the thread.

Expected behavior

The turn shows as Limited, with Resume. The docs define Limited as "the provider stopped on a usage or rate limit", and T3 already shows it when the same 429 exhausts Codex's retries.

Actual behavior

• The thread stays Working with "Retrying provider (1/5)".
• The retry item has class transport_error, code responseStreamDisconnected, message exceeded retry limit, last status: 429 Too Many Requests.
• Codex reports every retry it schedules as responseStreamDisconnected with httpStatusCode: 429 (notify_stream_error in codex-rs). It then sleeps until Retry-After before the next attempt (responses_retry.rs, no cap). Over WebSocket it first reconnects five times and falls back to HTTPS.
• On a real 0.1.6-nightly.20261031.3956 server, a turn sat at retry 1/5 for 38½ hours until it was stopped. Stopping records an interruption and a server restart cancels the run; neither shows Limited.

Before (main 01a93e7b51)

Impact

Major degradation or frequent failure

Version or commit

main 01a93e7b51; also 0.1.6-nightly.20261031.3956

Environment

Linux x64, Node 26.12.1, web client. Codex CLI 0.166.0 against a local CLIProxyAPI (dev, 7cad1cb7) whose two Codex credentials point at a mock upstream returning OpenAI's usage_limit_reached.

Logs or stack traces

Retry item stored by main (statev2.sqlite):

{"status":"running","failure":{"class":"transport_error","message":"exceeded retry limit, last status: 429 Too Many Requests","code":"responseStreamDisconnected","retryable":true},"retry":{"attempt":1,"maxAttempts":5,"retryDelayMs":null}}

Workaround

Stop the turn and resume it after the reset. Separately, CLIProxyAPI can answer such pools with usage_limit_reached: router-for-me/CLIProxyAPI#7184 and #6647. Codex then stops at once, and current T3 shows Limited.

Proposed fix

In CodexAdapterV2:

• classify a Codex retry whose error info carries HTTP 429 as usage_limit, the same rule fix(server): classify Codex 429 retry exhaustion as a usage limit #17501 applies to responseTooManyFailedAttempts;
• if such a retry has not recovered after five minutes, interrupt the turn and report it failed on that usage limit. It then shows as Limited with Resume, and with "Resume at reset" when Codex has reported a reset time.

Retries that recover, and a user's Stop, keep their current outcome. No automatic resume is added (#16289).

Branch: ntindle:t3/codex-429-retry-limited. It changes the adapter and its replay tests:

• a stop after the grace period;
• no stop when the retry recovers within it;
• Stop during the wait stays an interruption;
• the existing 5xx retry case stays transport_error.

After (same setup, branch)

I'll open the focused PR once the intended behavior is triaged.