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

Open 💬 1 comment Opened Jul 18, 2026 by pip-install-skills

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 ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗