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

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

1. Retry policy options:

• single_response_timeout_retry_max_attempts (default maybe 1 or 2)
• optional backoff (fixed or exponential)

1. 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_