ChatGPT Codex HTTP/SSE can emit zero events for 600s; identical retry completes in seconds (gpt-5.6-sol)

Summary

ChatGPT-authenticated Codex HTTP/SSE requests to https://chatgpt.com/backend-api/codex can intermittently remain completely silent before the first Responses event: no SSE event and no explicit HTTP error reaches the client. Retrying the same request immediately can complete in 5–8 seconds.

The 120-second observation below was not natural recovery after 120 seconds. It was forcibly terminated by a local finite-TTFB watchdog equivalent to the proposed Hermes mitigation NousResearch/hermes-agent#62997. Without that guard, the same failure mode has already remained silent until the client's 600-second wall-clock stale timeout on a fresh conversation; larger requests have reached 900/1200-second timeout floors.

Environment

• Model: gpt-5.6-sol
• Authentication: ChatGPT OAuth
• Affected transport: HTTP SSE / Responses streaming
• Client: Hermes Agent v0.18.2 (2026.7.7.2), OpenAI Python SDK 2.24.0
• Platform: Linux Telegram gateway
• Endpoint: https://chatgpt.com/backend-api/codex
• Official control client: Codex CLI 0.144.4 using responses_websocket

Evidence 1: default large-request behavior waited 600 seconds

This was a fresh Telegram gateway conversation with history=0; no tools had run before the affected call. Fixed system/tool-schema overhead put the request above the client's 10K-token large-request threshold.

2026-07-14T04:30:49.285Z  fresh conversation turn started (history=0)
2026-07-14T04:30:50.346Z  request started; estimated input ~23,048 tokens
                              no-first-event watchdog disabled for large request
2026-07-14T04:40:50.557Z  still zero events; wall-clock stale timeout killed request at 600s
2026-07-14T04:40:54.965Z  identical request retry started
2026-07-14T04:41:02.807Z  retry completed (~7.8s after retry start)

The provider later reported 18,969 input tokens. A second stall in the same session, after context grew to about 90K estimated tokens, remained silent until the 900-second floor; its retry completed in about 22.7 seconds.

Full public evidence and additional logs are in NousResearch/hermes-agent#61778, especially this fresh-session reproduction.

Evidence 2: finite watchdog bounded another stall at 120 seconds

A later run used a local build containing the finite large-request TTFB watchdog proposed in NousResearch/hermes-agent#62997. This converts an otherwise unbounded first-event wait into a 120-second abort and retry.

2026-07-14T06:01:14.893Z  request started; approximately 20,204 input tokens
2026-07-14T06:03:14.928Z  client aborted after 120.035s with zero SSE events
2026-07-14T06:03:19.344Z  identical request retry started
2026-07-14T06:03:24.679Z  retry completed in 5.335s

No OpenAI request ID was exposed for the zero-event attempt because no response event or explicit HTTP error reached the client.

The key point is that 120 seconds is the mitigation, not the underlying severity. Without that local patch, this request would have fallen back to the 600-second stale floor; requests above 50K/100K tokens can wait 900/1200 seconds in this client before reconnecting.

Official Codex CLI control and uploaded diagnostics

I also tested the same account/model through the official Codex CLI 0.144.4:

• 10 fresh sessions at 19,492 input tokens each: all completed; slowest 17.068s.
• 10 consecutive turns in one resumed thread, with reported request input growing as high as 215,327 tokens: all completed; slowest 17.163s.
• No official CLI request exceeded 60 seconds.

This does not disprove the HTTP/SSE issue: the official CLI selected responses_websocket, while the affected third-party client used HTTP SSE. It is useful as a transport/control comparison and suggests the prompt, account, and model were not inherently stuck during the test window.

The sanitized diagnostics were uploaded through the official Codex /feedback flow:

Feedback thread ID: 019f5f4b-1470-74f2-b452-c1024956bc36
Codex CLI result: Feedback uploaded

The uploaded report includes both the HTTP/SSE incident timestamps and the negative WebSocket control result.

Steps to reproduce

The backend/routing failure is intermittent rather than prompt-deterministic:

1. Authenticate with ChatGPT OAuth and use gpt-5.6-sol through the Codex Responses HTTP/SSE endpoint.
2. Send an ordinary agent request around 20K input tokens. A full system prompt plus tool schemas is sufficient; a long user conversation is not required.
3. On an affected attempt, observe that no Responses/SSE event and no explicit error reaches the client for minutes.
4. Abort the silent attempt and immediately retry the same request.
5. Observe that the retry can begin streaming and complete within seconds.

Expected behavior

A request should either:

1. emit an initial Responses event within a finite, documented interval;
2. return a structured error with a request ID;
3. or be safely retried/resumed by the client without waiting 10–20 minutes.

Ideally the transport should expose phase-specific telemetry for request sent, headers received, first byte, first Responses event, retry reason, and terminal state.

Actual behavior

An HTTP/SSE attempt can remain in a zero-event state with no actionable error. Without an independent client watchdog, automated agents can block for 600–1200 seconds, and an enclosing job/subagent timeout may destroy completed work before the per-request retry is reached. Immediate retry often succeeds quickly.

Why this does not look like ordinary slow prefill or reasoning

• The affected fresh-session request had only 18,969 provider-reported input tokens.
• No first Responses event arrived at all.
• The identical retry succeeded in 5–8 seconds.
• The same account/model completed 20 official WebSocket control requests without a comparable stall.

This does not prove whether the root cause is backend admission, routing, HTTP streaming, or another transport layer; it does show that a client cannot safely interpret the silence as legitimate model work indefinitely.

Related reports

• openai/codex#24260: long pre-first-output stalls, including later HTTP transport evidence and fast recovery after interrupt/resubmit.
• openai/codex#32366: HTTP fallback returns successfully but produces no stream events, primarily on an existing long-running Desktop thread behind a local proxy.
• openai/codex#30474: generic configurable response-timeout request.
• NousResearch/hermes-agent#61778: client-side watchdog blind spot plus multiple live gpt-5.6-sol reproductions.
• NousResearch/hermes-agent#62997: open mitigation PR that keeps a finite first-event watchdog for large requests.

This report adds a fresh-conversation 600-second reproduction, an independently bounded 120-second zero-event/retry pair, gpt-5.6-sol evidence from Linux, and an official WebSocket control/feedback thread.