Repository navigation
Windows desktop: repeated WebSocket idle timeouts, ~46-minute activity gap, and misleading post-recovery assistant response #50086
Description
Problem
During a long-running Codex desktop task on Windows on October 1, 2026, the response stream repeatedly disconnected. The user received no root-agent response for approximately 40 minutes. The agent's recorded tool activity has an approximately 46-minute gap, from 19:18 to 20:04 UTC (15:18–16:04 America/New_York). This gap is an observation, not proof that the transport was disconnected for every second.
User-provided screenshots show Reconnecting 2/5 and Reconnecting 4/5, with this expanded error:
stream disconnected before completion: idle timeout waiting for websocket
A subagent completion indicator remained visible above the reconnect message. A separately running local background process completed its scheduled work during the gap; that does not establish continuity of the root response stream.
Assistant behavior after recovery
When the user asked whether the assistant was offline, it initially responded:
I'm here. I should have kept you updated more promptly.
It then gave a project update without acknowledging the connection failure. This was misleading: it framed a visible stream interruption as delayed communication and had no evidence that it was continuously connected or executing through the gap.
Only after the user challenged the answer with the screenshots did the assistant acknowledge the interruption, retract any implication of continuous activity, and apologize. The user explicitly requested this report.
Expected behavior
- Recover the interrupted turn while preserving accepted user messages, tool results and subagent work.
- Clearly distinguish a stream interruption/retry from active reasoning or tool execution.
- On resumption, make the interruption status available to the assistant so it can acknowledge the failure accurately.
- The assistant should say that continuity and the underlying cause are unknown when it cannot establish them, rather than imply it was working throughout the gap.
Environment and evidence limits
- Installed Windows desktop package observed after recovery: OpenAI.Codex 26.928.3736.0.
- Locally resolved Codex CLI: codex-cli 0.159.2. This is the resolved CLI version, not proof of the exact backend binary serving the failed request.
- Date/time window: 2026-10-01, approximately 19:18–20:04 UTC.
- Reproduction is intermittent; no deliberate disconnection, application restart or OS reboot was performed to reproduce it.
- The screenshots establish the reported error and retry UI. They do not establish whether the initiating cause was the local network, client, intermediary or OpenAI service.
- Local app-log inspection is in progress. No full logs, session transcript, project files, credentials or account information are attached to this public report.
Similar symptoms appear in #47009 and #45497. A shared root cause is not established. Please link to a canonical issue if appropriate.
Requested investigation
Please investigate recovery from repeated WebSocket idle timeouts and whether transport failure/recovery status is reliably supplied to the assistant. Please also review the misleading post-recovery answer described above. Please specify the supported diagnostic identifiers or redacted trace fields needed for server-side correlation.
Reporting route checked against the official guidance: https://learn.chatgpt.com/docs/reference/troubleshooting
Activity
akchumbley commentedon Oct 1, 2026
The user additionally reports that their banked usage balance fell considerably during the last hour, despite the visible disconnection. This is a user-reported observation; no before/after account snapshot or request-level billing record is available to establish the amount or attribute it to the failed stream.
Scoped inspection of this installation's October 1 app logs found seven pubsub close/reopen cycles within 19:18–20:04 UTC (19:27:05.931, 19:28:25.922, 19:29:31.927, 19:44:49.952, 19:58:43.888, 19:59:29.882 and 20:03:11.879). They have no close code or causal reason, and pubsub is separate from the model response stream. The logs do not contain the screenshot's exact model-stream timeout text, credit-balance snapshots or token-usage records for that window. Unidentified completion notifications cannot be counted as identifiable billed requests.
Please also investigate whether server-side generation, automatic retries or independently running subagents can continue consuming usage while the desktop response stream is disconnected, and clarify how customers can obtain request-level attribution for such an incident. No claim is made that retries caused this debit, and the pubsub events do not establish a common cause. Private account balances and raw logs have been omitted from this public issue.
akchumbley commentedon Oct 1, 2026
Additional evidence: the user supplied a credit-balance screenshot taken at 13:22 America/New_York on October 1, and a fresh account-wide API read was timestamped 20:33:24–20:33:26 UTC (16:33 local). A net balance drawdown is now established over that wider 3-hour-11-minute window. It includes time before and after the response-stream interruption, so it still does not establish an outage-only debit, a debit attributable to this task, or gross consumption. Exact balances and screenshots remain local rather than being posted publicly.
The persistent task goal was also observed as Paused, with last-updated time 19:34:19 UTC inside the interruption window. The reporting agent did not change that status and cannot establish its origin from the available records. After the user's explicit instruction to continue, a new read at 20:33:26 UTC confirmed Active. This is a separate status observation; no claim is made that it caused the WebSocket timeout. Please include goal-state recovery and credit attribution in the investigation.