2026-10-06
A Codex turn can wait forever before the first byte
Codex #51258: the Responses HTTP path has no connect/headers timeout — a hung attempt never errors, never retries, and can sit hours. Observed in Desktop (bundled cli 0.160.0).
Codex #51258 (Desktop build 26.930.51102, bundled cli 0.160.0) describes an intermittent hang: a tool call finishes, the next Responses HTTP request is assembled, and then nothing — no headers, no stream events, no timeout, no retry. One reported task stayed marked running for about five hours; another sat past fifty minutes under inspection. Other tasks in the same app-server kept producing events. The computer was not asleep. Interrupting the stuck turn and continuing restored progress once.
Source at main 822e58c matches the shape: the default HTTP client leaves connect_timeout unset (None), each attempt awaits transport.stream(req) with no deadline for response headers, and the SSE idle timeout only starts after the stream opens. Retries already treat Timeout as retryable — but an attempt that never returns an error never enters that path. A hung open gets neither a deadline nor a retry.
There is no deterministic repro yet; the report is honest about that. Operator advice: treat “no events after a completed tool call” as stuck, and run an external turn-age watchdog that kills or resumes the turn when the quiet window exceeds your tolerance. Do not wait for Codex to self-timeout on the pre-headers wait — it currently cannot.
Subscribe: /log/feed.xml