Streaming Responses POST has no timeout before response headers arrive

What version of Codex CLI is running?

Observed by source inspection at rust-v0.152.0; the same shape is present in 0.151.0.

What subscription do you have?

ChatGPT Pro, authenticated via OAuth.

Which model were you using?

Not applicable — this is a source-level observation about request construction, not a model-dependent behavior.

What platform is your computer?

Linux 4.4.302+ x86_64, Debian 13 (trixie) container, Node v26.8.1.

What terminal emulator and version are you using (if applicable)?

None. Codex runs headless and emits JSONL.

Codex doctor report

Not included — this report is a source-code observation and does not depend on local environment state.

What issue are you seeing?

A streaming Responses request has no deadline covering connection, upload, and the wait for response
headers. If the server accepts the connection but never returns headers, the request waits
indefinitely. The configured stream_idle_timeout does not help, because it is only applied after
headers have been received.

This is not the cause of the Git-resolution hang reported in #41984. That hang occurs before any
model request. We found this while tracing that hang and are reporting it on its own merits.

I do not have a reproduction for this — it is a code-path observation, not an observed failure.

What steps can reproduce the bug?

I do not have a reproduction. This is a code-path observation found while investigating #41984, reported on its own merits rather than as a suspected cause of that hang.

Reproducing it would require a server that accepts the TCP/TLS connection and then never returns response headers — for example a stub listener that completes the handshake and holds. Under that condition the source paths below show no deadline would fire.

What is the expected behavior?

A streaming Responses request should be bounded by a deadline covering connection, upload, and the wait for response headers, so it cannot wait indefinitely when a server accepts a connection but never responds.

Additional information

Source analysis

Links pinned to rust-v0.152.0:

• Provider::build_request
  constructs every request with timeout: None.
• The Responses endpoint awaits
  stream_encoded_json_with(...)
  without setting a timeout.
• EndpointSession::stream_encoded_json_with
  passes it to transport.stream(req).await.
• ReqwestTransport::stream
  awaits builder.send(); the transport applies a request timeout
  only when Request.timeout is Some.
• stream_idle_timeout reaches spawn_response_stream only after transport.stream has returned
  headers, and from there bounds
  stream.next() while consuming an established SSE body.
  It cannot interrupt upload or the pre-header wait.

Why this reads as an omission rather than a deliberate policy

Two sibling call sites in the same crate do bound their requests:

• file requests use an explicit OPENAI_FILE_REQUEST_TIMEOUT
• the compact endpoint sets req.timeout

If unbounded pre-header waiting were intentional for streaming, I would expect it to be documented or
consistent; the asymmetry suggests it was simply missed.

Suggested direction

Add a bounded request/response-header deadline covering transport.stream(req).await, kept distinct
from the post-header SSE idle timeout, with expiry routed through the existing transport retry/error
policy. A delayed-header transport test would prove the request terminates when no headers arrive.

Relationship to #41984

The primary issue is a proven lifecycle defect with a one-command reproduction and a clear fix. This
one is a plausible robustness gap found by reading code. Bundling them would let the weaker item drag
the stronger one through triage, and the two have different owners, different fixes, and different
evidence quality. Filing separately lets each be judged on what it actually shows.

Start with Provider::build_request in codex-rs/codex-api/src/provider.rs, the Responses endpoint and EndpointSession, then follow ReqwestTransport::stream in codex-rs/http-client/src/transport.rs. Compare the bounded file and compact request paths with the post-header stream_idle_timeout handling. Done means a delayed-header transport test shows the streaming request terminates and uses the existing retry/error policy.