[macOS Desktop] Repeated WebSocket disconnects followed by server errors over HTTPS; remote compaction also fails at 73% context #53484

Environment

• Codex Desktop: 26.1007.30912, build 20156; update check reported up to date
• Bundled Codex CLI: 0.162.0-alpha.17.2
• OS: macOS (exact OS version not collected)
• Authentication: ChatGPT sign-in
• Model: gpt-6.1-sol, high reasoning in the affected desktop conversation
• Observed on October 12, 2026

What happened?

An existing desktop conversation repeatedly fails before completing a response. The client retries up to five times with:

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

After automatic fallback to HTTPS, the response stream instead reports:

stream disconnected before completion: An error occurred while processing your request.

Manual /compact also fails:

Error running remote compact task: stream disconnected before completion: An error occurred while processing your request.

The UI showed 73% context usage. No context-length-exceeded error was observed. This blocks both continuing the existing conversation and compacting it.

Steps observed

1. Continue an existing conversation with substantial image-viewing history.
2. Observe repeated WebSocket failures and retries.
3. Observe automatic HTTPS fallback also returning an error inside the response stream.
4. Attempt /compact in the affected conversation; remote compaction fails too.

This is reproducible in the affected conversation; a minimal public reproduction and the same-model/high-reasoning fresh-conversation comparison have not yet been established.

Diagnostics and attempted workarounds

• The system HTTP, HTTPS, and SOCKS proxies were disabled.
• Logs confirmed a successful WebSocket connection before the premature close.
• HTTPS fallback reached the server and received HTTP 200, followed by the processing error in the stream.
• The affected request was approximately 25.4 MB before zstd compression and 18.3 MB after compression. Its history included 83 image-view records. These are diagnostic clues, not a confirmed root cause or evidence of exceeding the token context limit.
• Two short requests using the bundled CLI, the existing sign-in, and the same model succeeded with a custom HTTPS provider configured with supports_websockets = false. These were short low-reasoning requests, so they are not equivalent reproductions of the failing conversation.
• Changing the default provider to that custom HTTPS provider did not change the already-existing desktop conversation's recorded built-in openai provider. The desktop conversation continued using WebSocket until its own automatic fallback.
• The official help-center AI support conversation received this report but stated that it could not create a ticket, escalate to a human, or query backend logs using request IDs, and suggested this repository's issue channel.

Expected behavior

The existing conversation should complete responses or recover successfully. Manual compaction should work, or the client should report a specific actionable failure instead of repeatedly returning a generic stream error.

Please investigate whether this involves conversation state, image-heavy request handling, remote compaction, or the desktop transport/recovery path, and provide a supported way to recover the existing conversation.

Privacy

This report intentionally excludes email addresses, request IDs, conversation/session IDs, local file paths, original conversation content, and raw logs. No root cause is asserted.