Feature request: configurable per-response timeout cap with automatic retry on overrun #30474

What variant of Codex are you using?

App

What feature would you like to see?

Summary

Add a configurable client-side cap for single response duration (especially for streaming responses).
If one response exceeds this cap, treat it as a server-side abnormal condition and automatically retry the request.

Problem

Currently, response duration is indirectly affected by reasoning effort tiers, but there is no explicit per-request/per-turn timeout cap that users can set to enforce a strict upper bound for one response.

In unstable network/server conditions, a single stream may hang or run much longer than expected, and users cannot apply a deterministic timeout + retry policy at the Codex client level.

Proposed behavior

Add a new configuration option (name can be discussed), for example:

• single_response_timeout_ms (or single_response_timeout_seconds)
• Scope: global config + optional per-command override

When enabled:

1. Start a timer when a response request begins (streaming included).
2. If the timer exceeds the configured cap before completion:
   • classify as timeout/abnormal server behavior
   • cancel the in-flight request
   • automatically retry with configurable retry policy
3. Retry policy options:
   • single_response_timeout_retry_max_attempts (default maybe 1 or 2)
   • optional backoff (fixed or exponential)
4. If all retries fail, surface a clear error to the user.

Error handling / safety

• Retries should be safe and predictable:
  • include idempotency key or turn/request identifier where possible
  • avoid duplicate side effects for tool calls
• Log timeout-triggered retry attempts in debug logs and telemetry.
• Distinguish:
  • connect timeout
  • read/stream stall timeout
  • total response wall-clock timeout (this feature)

Why this helps

• Gives users deterministic latency control.
• Improves resilience for long-lived streaming requests.
• Reduces manual interruption/retry workflows.
• Makes behavior easier to automate in CI/agent environments.

Possible implementation hints

• Reuse existing request timeout plumbing where available (req.timeout) but add a dedicated wall-clock guard for streaming lifecycle.
• Add config parsing + validation.
• Add integration tests:
  • stream exceeds cap -> cancelled -> retried
  • succeeds on retry
  • exceeds cap across all retries -> fails with explicit error

Additional information

No response