[Bug]: Codex HTTP 429 retry exhaustion hides Limited state and manual Resume #16288

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

Impact

Minor bug or occasional failure. The original stop interrupted an active task; a new user message continued the same native session.

Workaround

The user typed go on, and a second run began in the same native provider session with further tool activity.

Summary

A Codex turn stopped with an explicit HTTP 429 after exhausting provider retries. T3 Code displayed Failed and a generic provider error instead of the documented Limited state and manual Resume control. This interrupted an active task. Sending a new user message later started a continuation in the same native provider session, so this report concerns the missing limit classification and recovery control, not an unrecoverable conversation.

Steps to reproduce

These are the observed incident conditions, not a deterministic reproduction. A fresh rate-limit reproduction was not run.

1. Start a Codex coding task in the desktop app using the runtime listed below. The observed turn performed tool calls and delegated work to three subagents through a custom provider route.
2. While the turn is active, the provider exhausts retries and returns exceeded retry limit, last status: 429 Too Many Requests with the error code responseTooManyFailedAttempts. The request conditions that caused the provider to return 429 are unavailable.
3. Inspect the thread immediately after termination. The supplied screenshot shows Failed, a Provider error item, and an empty composer with the send control rather than the documented limited-turn Resume control.
4. Inspect the persisted failure classification. The observed incident records provider_error, not usage_limit.
5. As a separately observed workaround, send a new continuation message. A later user message started a second run using the same native provider session and further tool activity appeared.

Expected behavior

T3 Code's documentation defines Limited as a provider stop on a usage or rate limit and promises manual Resume in an empty composer. Providers without a reset time still offer manual retry. An explicit HTTP 429 retry-exhaustion stop should retain that rate-limit recovery behavior. This does not require scheduling an automatic continuation when no reset time is known, or treating every responseTooManyFailedAttempts error as a rate limit.

Actual behavior

The original run ended in failed. The persisted provider thread became idle, with no queued continuation or unfinished run at the initial inspection. The error item contained the following sanitized fields. Two subagents ended in failed and one ended in completed; their failure causes were not independently established.

{
  "class": "provider_error",
  "message": "exceeded retry limit, last status: 429 Too Many Requests",
  "code": "responseTooManyFailedAttempts",
  "retryable": null
}

The screenshot's sidebar showed Failed. A later user-authored continuation message started another run in the same native provider session. Manual continuation therefore worked in this incident, but the rate-limit-specific state and empty-composer recovery control were absent at the original stop. No controlled failure rerun or fix verification was performed.

Evidence

• Expected source: The installed build's thread recovery documentation, under Inspect agent work, defines the Limited state, manual Resume, reset-time scheduling, and manual retry without a reset time.
• Failure source: Read-only inspection of the live v2 store's orchestration_v2_projection_turn_items.payload_json.failure, run and provider-thread projections, and a supplied screenshot of the same failed thread. The sanitized failure fields are reproduced above. A subsequent snapshot records a user-authored continuation and a second run with further tool activity.
• Evidence provenance: observed
• Local verification: not-run
• Reproduction completeness: incomplete
• Missing fact: The provider-side request and rate-limit conditions, or an isolated fixture that faithfully produces this explicit HTTP 429 terminal error; original response headers and reset information are unavailable.

The persisted failure, run state, and later continuation were inspected directly; the UI evidence comes from the user-supplied screenshot. Investigation inspected retained incident evidence and source documentation and did not induce a new provider rate limit. The original screenshot and transcripts contain private context and are not attached. Inline evidence preserves the error and state needed for this report while omitting session identifiers, private task content, and machine paths. The persisted failure does not identify whether the 429 originated at the custom route or its upstream service.

Source inspection of the installed revision provides investigation locators. In apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts, codexErrorInfoCode extracts the error variant key, and both terminal failure mappings classify only usageLimitExceeded and rateLimitExceeded as usage_limit. In apps/web/src/components/ChatView.tsx, resumableRunId admits a failed run only when the runtime and root failure both have usage_limit. These source observations explain the available recovery path; they do not establish the upstream cause of the 429 or replace a fresh reproduction.

Restoration check

With an isolated Codex turn that terminates in explicit HTTP 429 retry exhaustion, verify that the thread exposes the documented Limited state and manual Resume with an empty composer, including when there is no reset time. After the provider accepts requests again, manual Resume should continue the same conversation and preserve previous work. Use a non-429 retry-exhaustion error as a control: it should keep its applicable error handling rather than gain a misleading rate-limit state. These checks remain unexecuted in this report.

Version or commit

The running desktop installation reports T3 Code Nightly 0.0.46-nightly.20261005.2702 in both its app metadata and bundled package manifest. The retained native transcript reports Codex CLI 0.160.1; the selected model was gpt-6.1-sol, with ultra reasoning and the default service tier. The session used a custom provider route. Its upstream request path and original HTTP headers are unknown. The documentation citation pins the source revision reported by the bundled manifest. No reproduction on another build was attempted.

Triage assessment

• Impact level: P2
• Assessment status: supported
• Impact basis: One retained incident stopped an active coding task and hid the documented rate-limit state and manual recovery control. Wider frequency and affected-provider reach are unknown; no data loss was observed.
• Workaround status: available
• Workaround basis: A later user-authored continuation message started a second run in the same native provider session with further tool activity. This preserves the conversation but requires the user to notice the stop and send another message; completion of the coding task was not evaluated.