[Windows Desktop] Responses streams can hang for 7+ hours after network interruption while turns remain InProgress

What version of the Codex App are you using?

Two different version identifiers are visible in local diagnostics:

• Runtime client_version: 26.814.41957
• Windows AppX package version: 26.814.5517.0

These are not “affected” versus “current” builds. No app update occurred during the incident window (approximately 02:25–09:08 UTC+8).

What platform are you using?

• Codex Desktop on Windows x64
• Local project thread
• A TUN/transparent-routing proxy path was present via v2rayN/xray
• Windows system proxy and WinHTTP proxy were disabled/direct

Which models and reasoning settings were active?

Two model requests stalled at nearly the same time:

• Parent turn: gpt-5.6-sol, reasoning effort max
• Child agent: gpt-5.6-luna, reasoning effort max

This was a multi-agent task. The affected events were model sampling calls using the Responses endpoint, not a local shell command that was still running.

Summary

A temporary network/proxy-path interruption appears to have triggered the incident, but Codex Desktop did not bound or reconcile the stalled Responses requests.

Both requests were opened around 02:25 UTC+8. Neither produced HTTP response headers, a request ID, output events, a completion event, or a structured error. The affected turns remained persisted as InProgress for more than seven hours.

When connectivity returned, Codex emitted retry/timeout messages for later sampling requests and eventually completed a new request, but the original stalled state had not been converted into a terminal failure or otherwise reconciled automatically.

The core issue is therefore not that a proxy or network interruption can occur. The core issue is that a lost stream can remain non-terminal indefinitely, leaving the task and UI appearing to be actively working.

Sanitized timeline (UTC+8)

2026-08-20 02:25:09.956  Last nearby successful child request
                            x-request-id: 7d0092a7-580d-42cd-adcc-5143559a5e03

2026-08-20 02:25:13.528  Child Responses request opened
                            model=gpt-5.6-luna, effort=max
                            No headers, request ID, output, completion, or error followed

2026-08-20 02:25:50.657  Last nearby successful parent request
                            x-request-id: d50a89f5-6167-402d-ba26-67fecb3dcd10

2026-08-20 02:25:58.700  Parent Responses request opened
                            model=gpt-5.6-sol, effort=max
                            No headers, request ID, output, completion, or error followed

2026-08-20 09:08:51      Stale tool/MCP tasks were cancelled during recovery

2026-08-20 09:08:59.480  Persisted state still reported:
                            active_turn_present=true
                            active_turn_status=Some(InProgress)

2026-08-20 09:09:54      Windows NetworkProfile event 10000: network connected

2026-08-20 09:10:05.256  stream disconnected - retrying
                            sampling_error=request timed out
2026-08-20 09:10:20.480  stream disconnected - retrying
                            sampling_error=request timed out
2026-08-20 09:10:35.864  stream disconnected - retrying
                            sampling_error=request timed out
2026-08-20 09:10:51.624  stream disconnected - retrying
                            sampling_error=request timed out
2026-08-20 09:11:08.175  stream disconnected - retrying
                            sampling_error=request timed out

2026-08-20 09:11:26.265  A later Responses request opened
2026-08-20 09:11:29.399  HTTP 200 headers received
                            x-request-id: 55d707d6-7c81-45fa-8d73-62e31467b3df
                            Output events then completed normally

There were no matching sleep, hibernate, reboot, or power-loss events during the seven-hour gap. The same backend process remained alive.

No request IDs are available for the two hanging requests because neither request ever logged response headers.

Steps to reproduce

This is intermittent, but the observed sequence was:

1. Start a long-running multi-agent task in Codex Desktop on Windows.
2. Have the parent and child issue Responses sampling requests.
3. Interrupt the network path while one or more response streams are waiting.
4. Restore connectivity later.
5. Observe that the original requests may emit no terminal event and the corresponding turn remains InProgress indefinitely.
6. The UI continues to display a thinking/running state even though no new events are arriving.
7. Later requests may retry and succeed without automatically reconciling the original stale active turn.

The local network path used v2rayN/xray through TUN/transparent routing, not the Windows system proxy. This is a plausible trigger. It may also involve secure WebSocket behavior or an idle timeout somewhere along the proxy/TLS path, although the captured affected calls were logged as responses_http, so the exact transport failure boundary is not proven.

Expected behavior

After bounded inactivity or a broken stream, Codex should do one of the following:

• reconnect/resume the stream safely;
• retry with a bounded deadline;
• fall back to another supported transport;
• terminate the request with a structured timeout/network error; or
• reconcile the persisted turn to a recoverable terminal state and present a Retry/Continue action.

A stale request must not keep active_turn_status=InProgress for hours without events.

On application/network recovery, Desktop should compare local active-turn state with the actual request/stream lifecycle and clear or explicitly recover stale InProgress turns.

Actual behavior

• Two Responses requests opened.
• Neither produced headers, request IDs, output, completion, or error.
• The turn remained InProgress for more than seven hours.
• Connectivity recovery did not immediately reconcile the stale state.
• The UI made the inactive task appear to still be working.

Suggested fix direction

• Add a model-stream inactivity watchdog outside the individual model/tool call.
• Put an end-to-end hard deadline around request start → headers/first event and around long periods with no stream events.
• Persist enough stream lifecycle state to distinguish waiting-for-headers, actively-streaming, reconnecting, and stale.
• On reconnect/startup, reconcile persisted InProgress turns that have no live request/stream owner.
• Surface an explicit recovery action rather than an indefinite “Thinking” state.
• Log transport type, stream open/first chunk/last chunk/terminal event, retry generation, and request ID when available.

Related but not exact duplicates

• #36059 reports Responses WebSocket/HTTPS disconnects and fallback failures, but those requests enter retry/fallback paths rather than silently remaining non-terminal for seven hours.
• #34026 reports completed backend turns that remain visually “Thinking”; here the persisted turn itself remained InProgress.
• #24951 reports multi-agent tools exceeding their timeout during a runtime stall; here the strongest evidence is two model Responses requests that never received headers or terminal events after a network interruption.

Privacy note

No project content, credentials, cookies, local filesystem paths, or full raw session logs are included. The timestamps and request IDs above are provided for server-side correlation. A narrower sanitized log slice can be provided if maintainers request it.

Start with the Responses endpoint and model-stream lifecycle, then trace how persisted active-turn state is handled during recovery and startup. Check how waiting-for-headers, retries, inactivity, and terminal events are represented. Done means an interrupted stream reaches a bounded terminal or recoverable state and the UI no longer shows an indefinitely active turn.