[macOS app] WebSocket closes before response.completed during an active Codex task; Reconnecting 5/5

What version of the Codex App are you using (From “About Codex” dialog)?

26.901.31953, released September 3, 2026.

The About dialog identifies the application as ChatGPT — Powered by Codex & OWL. This occurred in its Codex workspace, not the CLI or IDE extension.

What subscription do you have?

ChatGPT Pro (20x).

What platform is your computer?

• macOS Tahoe 26.6.2
• MacBook Pro, 16-inch, Apple M5 Max
• 128 GB memory
• Selected model/settings as displayed in the app: GPT-6 Astra / Ultra
• Permission mode: Full access

What issue are you seeing?

During an active coding task, the app displayed Reconnecting 5/5 with this exact error:

stream disconnected before completion: websocket closed by server before response.completed

The task involved reading and editing files, running commands, reviewing images, and using subagents while debugging an iOS app navigation/animation issue. The run timer showed approximately 23 minutes when the screenshots were taken; this is an observation, not a confirmed timeout threshold.

The UI still showed an active “Pursuing goal” run and a stop button while the reconnection status was visible. A subsequent screenshot also showed task/tool activity alongside “Reconnecting 5/5,” making it unclear whether the stream had recovered or the run was still in a disconnected state. I cannot confirm from these captures whether the underlying task ultimately completed or failed.

What steps can reproduce the bug?

Observed workflow, rather than a confirmed deterministic reproducer:

1. Open the macOS desktop app and start a local coding task in the Codex workspace with GPT-6 Astra / Ultra and Full access.
2. Let the agent work through file reads/edits, commands, image inspection, and subagent work.
3. During the run, observe “Reconnecting 5/5” and the WebSocket error above.
4. The run still appears active, leaving its connection/recovery status unclear.

Token/context usage at the time of the error was not captured. The exact trigger, recurrence rate, VPN/proxy involvement, and behavior after restarting the app have not been established.

What is the expected behavior?

The response stream should remain connected until completion. If the connection drops, the app should reconnect and clearly indicate that the run has resumed, or show an unambiguous failure state with a recovery action. It should not leave the user guessing whether an apparently active task is still disconnected.

Additional information

In-app feedback was submitted successfully with diagnostic logs enabled. The confirmation dialog returned:

Feedback ID: 01a06fbb-776e-71d2-ae67-d1b65fa163a2

Please use this feedback ID to correlate the diagnostic logs with the stream interruption and reconnect attempts.

This report concerns the Codex response-stream disconnection, not a failure to submit feedback. The error text reports a server-closed WebSocket, but the root cause has not been independently diagnosed.

The error, UI state, feedback ID, application version, and system specifications above were transcribed from screenshots. Original screenshots are not attached to this issue. Device serial number and unrelated project/account details have been omitted.

Begin with the diagnostic logs associated with feedback ID 01a06fbb-776e-71d2-ae67-d1b65fa163a2 and examine the macOS app's WebSocket reconnect behavior around the server-close event. Compare the Reconnecting 5/5 state with subsequent task activity to determine whether the run resumes or fails. Done means the disconnect outcome is unambiguous and recovery or failure is clearly surfaced.