Allow configuring retry policy and honor `Retry-After` for TPM rate limits in Codex

Open 💬 2 comments Opened Jul 18, 2026 by pip-install-skills
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

IDE Extension

What feature would you like to see?

Summary

When Codex encounters an OpenAI TPM (Tokens Per Minute) rate limit during a long-running streaming task, it performs a fixed number of reconnect attempts (currently 5) and then terminates the agent.

For large repositories and long-running coding sessions, this frequently aborts otherwise recoverable tasks.

It would be very helpful if Codex exposed a configurable retry policy and honored the server's Retry-After guidance instead of terminating after a fixed reconnect count.

---

Current behavior

Example:

stream disconnected before completion:
Rate limit reached for gpt-5.6-sol

Limit: 500000 TPM
Used: 452786
Requested: 135822

Please try again in 10.632s

Codex then shows:

Reconnecting 1/5
Reconnecting 2/5
...
Reconnecting 5/5

After the fifth reconnect, the agent stops and requires manual intervention.

---

Expected behavior

Instead of aborting after a fixed number of reconnects, Codex should continue retrying until the request can be admitted, or until a configurable timeout/retry budget is reached.

Ideally:

  • Honor the server's Retry-After (or equivalent) delay when provided.
  • Fall back to exponential backoff if no retry delay is available.
  • Allow users to configure retry behavior.

Example configuration:

[retry_policy]
max_retries = 50
max_retry_duration = "30m"
retry_delay_seconds = 30
honor_retry_after = true

or simply:

retry_policy = "adaptive"

---

Why this matters

Large repositories and long conversations can easily produce requests exceeding 100k tokens.

Example:

Limit: 500000 TPM
Used: 451244
Requested: 137781
Please try again in 10.683s

These are usually temporary rolling-window TPM limits.

The agent already knows when it can retry, but instead exhausts its reconnect budget and exits.

Keeping the agent alive would allow long-running investigations and refactoring sessions to continue automatically without user intervention.

---

Environment

  • Codex CLI: 0.144.6
  • VS Code Codex extension
  • OpenAI API key authentication
  • Model: gpt-5.6-sol
  • Ubuntu 24.04
  • Large repository (~130k token requests)

---

Additional notes

I investigated the configuration options and confirmed that:

  • request_max_retries / stream_max_retries cannot be applied to the built-in openai provider.
  • There does not appear to be a supported way to configure reconnect count or reconnect delay for the built-in provider.
  • The server already returns a retry delay (Please try again in X seconds), which seems like a good candidate for adaptive retry behavior.

This would significantly improve reliability for users working with large repositories and long-running agent sessions.

Additional information

I spent some time investigating this before opening the feature request.

Things I verified:

  • Codex CLI 0.144.6 (latest available)
  • VS Code Codex extension
  • OpenAI API key authentication
  • codex doctor reports a healthy installation
  • Configuration loads successfully
  • I confirmed that request_max_retries and stream_max_retries cannot be configured for the built-in openai provider because it is reserved.

The server consistently returns messages such as:

  • Limit: 500000 TPM
  • Used: 451244
  • Requested: 137781
  • Please try again in 10.683s

However, Codex still performs only five reconnect attempts before terminating the session.

I'm not requesting a way to bypass rate limits. I want Codex to remain alive and automatically retry after the recommended delay (or another configurable delay) until the rolling TPM window has enough capacity again.

This is particularly valuable for long-running investigations on large repositories, where manually restarting the agent interrupts workflow and loses momentum.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #33661
  • #33853
  • #33257

Powered by Codex Action

tanjuntao · 15 days ago

I’m hitting the same fixed Reconnecting... 1/5 → 5/5 behavior, but not only for TPM/rate-limit cases. Ordinary transient network / streaming failures such as stream disconnected before completion can also exhaust the hard-coded retry budget and abort a long-running task that would likely recover with a few more attempts.

A particularly useful improvement would be to make the retry budget configurable for the built-in openai provider as well. Today stream_max_retries / request_max_retries are provider-scoped, but the built-in OpenAI provider is reserved, so normal ChatGPT/OpenAI users cannot simply raise the default retry count in config.toml.

For example, it would be helpful to support either a top-level setting such as:

stream_max_retries = 20

that overrides the built-in provider default, or a general retry policy like the one proposed in this issue.

I agree that honoring Retry-After plus bounded backoff is the better long-term design. The key requirement from my perspective is that temporary connectivity/stream interruptions should not automatically kill an otherwise healthy long-running Codex task after exactly five reconnect attempts.