Repeated idle timeout waiting for websocket disconnects within a single Codex task #27625

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on Jun 11, 2026
2. github-actions commented on Jun 11, 2026

   

   github-actionsBot

   on Jun 11, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Stream disconnects before completion with repeated 5/5 reconnect failures #26696
   • Repeated reconnect loops on home network make Codex unreliable and sometimes unusable #26274
   • Latest Codex repeatedly reconnects in old sessions and cannot start follow-up tasks #26720
   • Codex gets stuck in a pre-write context compaction loop on large projects, repeatedly re-reading instructions and never reaching file edits #27588

   Powered by Codex Action
3. vab2048 commented on Jul 26, 2026

   

   vab2048

   on Jul 26, 2026

   More actions

   Seems to be the same issue as reported in Sep 2025 #3355
4. SteinsHead commented on Sep 13, 2026

   

   SteinsHead

   on Sep 13, 2026

   Last edited by SteinsHead

   More actions

   Additional occurrence on Codex 0.154.0: automatic remote compaction V2 stalls for approximately 300 seconds, then retries with the same WebSocket idle-timeout error.

   This is a sanitized report from existing logs, not a deterministic reproduction or a claim that the underlying cause is identical to the original issue.

   Environment

   • macOS Codex desktop client connected over SSH to a Linux Codex app-server.
   • Remote CLI/app-server version: 0.154.0.
   • Model: gpt-6-astra, reasoning effort ultra, ChatGPT authentication, built-in OpenAI provider.
   • features.context_management.experimental_mode = true.
   • The observed model transport is TLS-protected WebSocket (responses_websocket). Detailed network topology is omitted for privacy; this report does not assert a direct connection.

   Observed timeline

   All times below are UTC on 2026-09-12. Entries are selected fields transcribed from existing structured logs, not a raw log dump.

   Time	Observation
   17:50:56	Normal tool execution completed. Context accounting reported auto_compact_scope_tokens=246703, auto_compact_scope_limit=244800, and full_context_window_limit=258400. token_limit_reached=true, but full_context_window_limit_reached=false.
   17:50:56	Entered run_auto_compact{reason=ContextLimit phase=MidTurn} and sent the request through responses_websocket; this attempt reported a reused connection.
   17:55:59	Logged remote compaction v2 stream failed; retrying request after delay, with retries=1 max_retries=2 and compact_error=stream disconnected before completion: idle timeout waiting for websocket. Approximately 303 seconds elapsed.
   17:56:00	A new WebSocket connection was established successfully and another compaction request was issued.
   17:56:48	The main task's session loop was still receiving inter-agent communication.

   At inspection around 17:57 UTC, no successful compaction record or resumed normal model output had appeared for this attempt. This is an observation cutoff, not evidence that the request could never recover. SSH and app-server status reads remained responsive; this does not establish that the outbound model stream was healthy.

   There was an earlier occurrence in the same long task: compaction around 16:54:24, followed by the same idle-timeout/retry at 16:59:28. Normal model activity was observed later. The symptom can therefore recur after recovery rather than being only a one-time startup failure.

   What this establishes, and what it does not

   • The visible stall coincides with a real automatic-compaction request and a logged WebSocket idle timeout, not merely a stale UI spinner.
   • Reconnecting the WebSocket can succeed without establishing that the compaction result has arrived.
   • It does not establish whether the missing response events originate in Codex connection reuse, the network path, or upstream service behavior. No packet trace or controlled network comparison was collected.
   • It does not prove the experimental context-management flag causes the failure. In the rust-v0.154.0 source, ContextManagement and the default-enabled RemoteCompactionV2 are separate features, and run_auto_compact selects V2 using provider capabilities and RemoteCompactionV2. Disabling the experimental flag is not equivalent to disabling V2 or automatic compaction.

   Relevant source: feature definitions and automatic compaction dispatch.

   Suggested investigation and regression coverage

   1. Use a synthetic long-history fixture and mock WebSocket server to cross the auto-compaction threshold. Exercise both reused and fresh connections, including a server that accepts the request but sends no response events, and one that disconnects partway through compaction. These are proposed tests, not tests already run here.
   2. Record phase-specific timing: request sent, first event received, last event received, retry start, and compaction completion. Distinguish no-first-event waits from mid-stream idle waits, without logging conversation contents or credentials.
   3. Verify bounded retry and cancellation behavior, preservation of the last valid conversation state, and exactly-once application of a successful compaction result. Surface the compaction phase and retry status clearly instead of only a generic reconnect indicator.
   4. Compare experimental context management enabled/disabled independently from connection reuse and transport. Avoid treating a blanket timeout increase, forced transport switch, or extra retries as a demonstrated root-cause fix.

   Related symptom report: #44464 (compaction with TLS EOF/fallback errors), but not asserted to have the same cause. PR #44487 preserves incoming prompts on pre-turn compaction failure; that is valuable but is not itself a fix for this mid-turn WebSocket idle timeout.

   No private conversation content, task IDs, hostnames, IP addresses, project paths, credentials, raw headers, or raw logs are included. No running tasks were interrupted or configuration changed while collecting this evidence.
5. machineyearningengineer commented on Sep 23, 2026

   

   machineyearningengineer

   on Sep 23, 2026

   More actions

   Additional occurrence on macOS 27.0 with Codex CLI 0.156.1 (23 September 2026). This is a sanitized summary of local diagnostic logs, not a deterministic reproduction.

   A GPT-6 Sol (medium) turn started at 17:59:08 UTC. It produced no completed model response or tool call. At 18:04:10, the client logged a sampling retry with stream disconnected before completion: idle timeout waiting for websocket; the turn was cancelled at 18:05:29 after 381 seconds. A later Sol turn starting at 18:29:58 was cancelled after 107 seconds without a completed response or tool call; it ended before the approximately five-minute idle timeout, so I cannot assign the same error to that turn. A subsequent GPT-5.5 (low) request completed in 49.8 seconds, with a recorded first-token time of 17.7 seconds.

   The noteworthy pattern is that idle-timeout retries were logged across several concurrent tasks and models on the same host:

   UTC time	Model
   17:33:21	GPT-6 Sol
   17:43:38 and 17:48:46	GPT-6 Luna
   17:59:03	GPT-6 Astra
   18:04:09 and 18:04:10	GPT-6 Astra and GPT-6 Sol, in different tasks
   18:14:26	GPT-6 Astra
   18:19:37	GPT-6 Astra, in two different tasks
   18:35:00 and 18:40:09	GPT-6 Astra

   Completed Sol turns in the affected task had recorded first-token times around 5–9 seconds. The simultaneous cross-model timeouts suggest a shared transport or upstream problem rather than a consistently slow Sol model. The logs do not identify whether the root cause was the local network, client connection handling, or the service.

   The five-minute delay before retry is especially disruptive because the UI can appear to be thinking with no actionable indication of the stalled stream. It would help to distinguish time waiting for the first response event from model computation and to detect or surface a dead stream sooner.