Repository navigation
[Windows / Codex Desktop + VS Code] Intermittent stream disconnects and reconnect failures since Oct 10 #52919
Description
Codex app version
26.1007.2314.0, taken from the installed Windows package metadata (not independently confirmed in the app's About dialog).
Subscription
ChatGPT Pro (user-reported).
Platform
Windows 11 25H2 (64-bit), Codex Windows desktop app.
Description
On 2026-10-10, the Windows Codex desktop app began repeatedly disconnecting and reconnecting. It had been working normally beforehand. The user signed in again after an unexpected disconnection; subsequently, ordinary prompts and longer tasks would intermittently succeed or fail after repeated Reconnecting… attempts. Remote context compaction also fails. This makes ongoing work unreliable.
Updated cross-client observation: Switching from the Windows desktop app to the VS Code Codex extension initially appeared to restore normal operation, but the VS Code extension subsequently disconnected as well (user report). The initial success in VS Code was therefore temporary and must not be treated as evidence of a desktop-only fault. The problem may affect a component shared by both clients. The root cause has not been established.
Locally collected evidence (2026-10-10)
Read-only analysis of the user's local Codex technical logs, covering the affected date, identified:
| Observation | Count |
|---|---|
| Terminal failed-task events across 5 session files | 22 |
| Ordinary response-stream failures | 18 |
| Remote Compact failures | 4 |
Desktop app_server_connection.websocket_error events |
261 |
Desktop app_server_connection.reconnect_failed events |
260 |
Desktop chatgpt_pubsub_connection_failed events |
41 |
Desktop chatgpt_pubsub_reconnect_exhausted events |
13 |
The desktop connection counts represent logged technical events, not distinct failed prompts. The session counts represent observed terminal failures in the inspected files, not a guaranteed complete incident total. These statistics alone do not establish which component is responsible.
Representative sanitized failed-task events (UTC; session/account identifiers and request IDs omitted):
2026-10-10 14:26:31Z | task_complete | response_stream_failure | stream disconnected before completion; An error occurred while processing your request.
2026-10-10 14:33:04Z | task_complete | remote_compact_failure | Error running remote compact task; stream disconnected before completion; An error occurred while processing your request.
UI errors included:
stream disconnected before completion: An error occurred while processing your request. You can retry your request, or contact us through our help center at help.openai.com if the error persists.
Error running remote compact task: stream disconnected before completion
Reproduction / comparison
- Run ordinary coding or conversation requests in an existing session in Codex Windows desktop.
- Intermittently the app displays repeated
Reconnecting…attempts and/or fails a task withstream disconnected before completion. - Remote compaction can separately fail with the same underlying stream-disconnect wording.
- Switch to the VS Code Codex extension on the user's Windows machine. Initial requests worked, but the user subsequently observed disconnections in the extension too.
The failures are intermittent; this is not a claim that every request reproduces them. The VS Code observations are user-reported and not controlled transport-level experiments. Web ChatGPT chat remaining accessible does not rule out intermittent failures in Codex requests.
Expected
Desktop should complete requests reliably, or safely recover and resume interrupted tasks without requiring users to switch clients.
Request to maintainers
- Investigate streaming/reconnection failures across Windows desktop and the VS Code Codex extension around Oct 10, including any shared service/transport path.
- Compare streaming reliability and recovery behavior across the clients and shared service components, without assuming the root cause.
- Provide a verified workaround, fix version, or diagnostics that can distinguish client behavior from upstream failures.
Additional diagnostic details can be provided privately to OpenAI Support if needed. Raw session files are not attached.
Possibly related: #52731, #52749, #37992. Symptom overlap does not establish a shared root cause.
Activity
github-actions commentedon Oct 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
[-][Windows Codex Desktop 26.1007.2314.0] Intermittent streaming/reconnect failures on Oct 10; VS Code extension works[/-][+][Windows / Codex Desktop + VS Code] Intermittent stream disconnects and reconnect failures since Oct 10[/+]Guilliman-XIII commentedon Oct 10, 2026
Further observations from the affected user:
The cause remains undetermined. Please investigate the failure events and correlate the request records through OpenAI Support.
luotao41 commentedon Oct 10, 2026
Additional sanitized observation on 2026-10-10: the same remote-compaction error text occurred while continuing an existing long-running cloud task. This is a symptom-level correlation with this report, not confirmation of a shared root cause or of a Windows-specific fault.
Observed sequence (all times UTC):
Error running remote compact task: stream disconnected before completion: An error occurred while processing your request. You can retry your request, or contact us through our help center at help.openai.com if the error persists. Please include the request ID ... in your message.
Request IDs shown with the two later remote-compaction failures:
Identifiers from the earlier stream-disconnect failures in this window:
Observed reproduction sequence: continue an existing long-running task; retry with smaller stages, including a read-only check and archive preparation; observe intermittent success followed by another failure at remote compaction before the requested output. This is not yet a deterministic minimal reproduction. The two successful stages did not establish durable recovery.
Expected: the task can resume reliably, or a supported recovery path preserves completed work. Please correlate the identifiers and timestamps above and advise on safe recovery. The failure's cause is unknown. No source code, task content, images, raw conversations, credentials, account details, or internal filesystem paths are included.
mhn13jp commentedon Oct 11, 2026
I'm getting the same error, seems to be triggered by compaction of threads that have been working with images in long running (2h+) threads. This is using Codex desktop for WIndows Version 26.1007.21434. I've never had problems with these kinds of tasks before. Chatgpt Pro subscription.
"Error running remote compact task: stream disconnected before completion: An error occurred while processing your request. You can retry your request, or contact us through our help center at help.openai.com if the error persists. Please include the request ID 33e8af0b-a076-45c3-8506-bda4b16b6105 in your message."
swenbo1-web commentedon Oct 11, 2026
Additional sanitized Windows desktop diagnostics — October 11, 2026
I observed repeated failures on Codex Windows Desktop 26.1007.2314.0 (installed package metadata), using gpt-6.1-sol / ultra, with HTTP Responses transport and model WebSockets disabled.
The recurring error was:
Read-only diagnostics found the following timeline. All timestamps below are UTC on 2026-10-11.
6eed0a36-9796-4ce5-8641-7d181e9901c1260d667a-8de9-44b3-9a52-4b0b4b7a78380211763e-3293-48f7-b800-016bff7c2ed06ae064cd-8078-453e-995b-4d00639a8c5e00125a14-da0e-4624-87b4-010d35085951Requests during the retry sequences returned HTTP 200 before the response stream failed. The 507 response body was not retained in the local logs, so its cause and relationship to the later stream failures remain unknown.
Reopening the conversation and submitting another turn did not prevent recurrence: the new turn began at 06:26:53, followed by the same processing error and a 1/5 retry at 06:27:16, request ID
6c8107b1-c524-463c-9e08-6e80c7654742. A later authoritative status snapshot confirmed that this turn completed successfully at 06:29:30. This retry recovered; it was not another terminal failure. One successful completion does not establish that the intermittent problem is resolved.The local backend process remained running. Recorded input was approximately 69,227 tokens against a 258,400-token context window; no explicit context-limit or quota-exhaustion error was found. A local system proxy is present, and its logs are insufficient to exclude a network-path contribution.
Please correlate these request IDs with backend records. The root cause is not established. No prompts, project contents, credentials, full transcripts, or databases are attached.
ericccliu commentedon Oct 11, 2026
Additional sanitized diagnostics from October 11, 2026. Adding evidence to this existing report because the visible symptom matches; a shared root cause is not established.
Environment observed locally:
A read-only inspection of one current local project conversation found three confirmed failed turns. These are task_complete records with a non-null error, not counts of retry notifications. All times below are UTC, October 11:
The terminal error text was:
Additional observations:
Observed reproduction: continue an existing long-running local conversation, observe intermittent stream failures, allow retries to reach 5/5, then receive a terminal error. A deterministic minimal reproduction is not available.
Please correlate the terminal request IDs and timestamps with backend records, and advise on diagnostics or a fix that distinguishes response-processing failures from the separate desktop TLS/reconnection failures. Raw transcripts, prompts, project contents, local paths, account identifiers, credentials, and database files are not attached. The inspection did not change settings or restart the running work.
wz787903-glitch commentedon Oct 12, 2026
I am experiencing the same recurring Codex streaming disconnection issue on Windows 11.
I have already submitted feedback through the Codex application's built-in feedback system.
Feedback / Affected Session ID:
01a0eb15-7c1d-7ce2-96c3-d76c3bf3b121
This identifier also matches the affected conversation ID in my local logs.
Environment:
Observed problems:
Relevant Request IDs:
Network observations:
I tested multiple VPN nodes, but the problem persisted. Completely disabling the VPN and proxy makes Codex inaccessible, so I cannot perform a meaningful direct-connection comparison.
I have submitted in-app feedback and previously collected filtered error logs. I would appreciate it if the maintainers could correlate the available feedback/session information with the Request IDs above and investigate the underlying cause.
Thank you.
Daviswhistle commentedon Oct 12, 2026
Additional report from Codex CLI/app-server under WSL2 on October 12, 2026. The visible error matches this issue; a shared root cause has not been established.
Environment verified locally:
codex-cli 0.162.1.gpt-6.1-sol, reasoning effortmax, built-in OpenAI provider.originator=codex-tuiandsource=vscode.Uploaded thread:
01a129c1-a1fa-7be3-b159-644db4e0dc77Codex feedback reported “Feedback uploaded” and requested that this thread ID be included in an issue.
Read-only inspection confirmed three terminal failed turns in this thread. All timestamps below are UTC on 2026-10-12; these are failed turns, not counts of retry notifications.
4e03107c-3923-4bf1-a93f-889148057aa25ee5fad2-e28b-4388-8945-ffa44164c00ac99e3fec-8577-401b-8bc2-ba941fca929bThe terminal error is:
Correlated observations:
5/5; the client loggedfalling back to HTTPat 08:37:00 and 08:53:10.200 OKbefore the turn failed. HTTP headers do not establish successful stream completion.codex_error_info: "other". No explicit context-window overflow error was recorded for these turns.Observed sequence: continue an existing long-running coding conversation, allow automatic retries/fallback, receive the terminal error, and retry a short continuation request. A deterministic minimal reproducer is not yet available.
Please correlate the uploaded thread and request IDs with backend records, identify the actual failure classification, and provide a supported recovery path that preserves the existing conversation and completed work. The high-demand message is an observation, not proof of the cause of every later processing error.
Only selected diagnostic facts and the uploaded-thread/request identifiers are included here; no raw transcripts, project content, credentials, account email, full headers, or database files are attached.
maxitaaaa commentedon Oct 12, 2026
I hit the same request-processing error in Codex Desktop for Windows on October 12, 2026. The matching local error was recorded at 12:06:54 UTC (20:06:54 UTC+08:00) while continuing an existing conversation.
Environment checked locally:
I submitted the exact request ID privately through Codex's
feedback/uploadinterface, which returned a successful response at 12:11:43 UTC. The returned feedback reference (threadId) is 01a12005-54ed-79a3-bb65-0cc9233c34c3. Logs were explicitly disabled and no attachments were included.Please correlate that feedback with the incident and identify the actual error. I need a supported way to continue the original conversation while preserving completed work. I do not have a deterministic minimal reproducer, and matching error text does not prove a shared root cause.
No prompts, business content, local file paths, credentials, full transcripts, or raw log files are included in this comment.
merusselllovetrain commentedon Oct 12, 2026
I’m also experiencing frequent reconnection failures. For roughly 10 days, about 8 out of 10 Codex sessions have become stuck reconnecting without completing the task, regardless of model or reasoning effort. My internet connection is stable, and other AI tools work normally. This makes Codex effectively unusable for daily work. Please investigate.
OS: Windows 11
Codex version: codex-cli 0.162.1
azq1231 commentedon Oct 13, 2026
Additional Windows Codex Desktop report — October 14, 2026 (UTC+8)
I am reporting another occurrence of the same stream disconnection before completion while using the Codex Windows desktop app to perform software development work. The issue has also occurred during longer-running coding tasks, causing work to stop before the response finishes.
Exact error shown:
Request ID:
73deefc2-4d4e-497d-831b-7a9c7d1c8d3dPreviously observed separate occurrence: October 12, 2026, with request ID
b6c46443-1548-4840-9ab1-9770850db43f(also interrupted a long-running Codex App programming task).Environment: Windows Codex desktop application. Exact Windows build, Codex app version, model, and precise failure timestamps have not yet been collected.
Impact: A coding task may run for an extended period and then lose its response stream before completion. This disrupts continuing work and makes it unclear whether the task completed all changes.
Could the Codex team investigate and correlate the two request IDs with server-side records, determine whether this is related to the ongoing Windows desktop reconnect/stream failures, and advise on a mitigation or fix?
No sensitive project contents or local paths are included in this report.
andersonwu2000 commentedon Oct 13, 2026
Same failure here on Windows, still ongoing as of 2026-10-14. Every hour or so a turn dies after "Reconnecting 5/5", and on a long goal thread almost no message gets through.
Environment
codex-cli 0.162.1(npm global; latest at the time of writing), TUI plus the background app-server daemon.gpt-6.1-solandgpt-6-astra, reasoning effortxhigh, ChatGPT login.OPENAI_*/CODEX_*environment variables, noopenai_base_urloverride inconfig.toml.What the local logs show (
~/.codex/logs_2.sqlite, targetcodex_core::responses_retry, 2026-10-12 to 2026-10-14). There were 200 retry warnings, grouped by error text:stream disconnected before completion: An error occurred while processing your requestWe're currently experiencing high demand, which may cause temporary errors.stream disconnected before completion: websocket closed by server before response.completedstream disconnected before completion: Responses websocket connection limit reached (60 minutes). Create a new websocketTransport error: network error: error decoding response bodycompact_errorinrun_pre_sampling_compact/run_auto_compact("remote compaction v2 stream failed"). So the pre-turn compaction of a long thread fails too, and that blocks the turn before sampling even starts.60 minutesconnection-limit message may explain the hourly rhythm. It looks as if the client does not open a fresh websocket cleanly when the limit is hit.failed to initialize thread persistence: thread-store conflict: thread ... already has an active writer. The TUI then reportedFailed to edit the selected prompt: the selected transcript prompt no longer matches the persisted thread. Here an app-server daemon started two days earlier and the TUI were attached to the same thread.Contrast: a fresh, tiny
codex exec --ephemeralrequest (gpt-6.1-sol) succeeds in about 5 s on the same machine and network. So auth and connectivity work, and the failures concentrate on long-running, large-context turns.Request IDs from failed turns (2026-10-14, UTC+8):
32f4939f-aefa-4a49-914e-91c874c8f9c6240f26af-c43f-4fe4-aaad-621d3914ed9c736a2f77-ec73-4a7c-9f3c-f7e1b9762dfaRequests:
An error occurred while processing your request/high demandstream aborts on long Sol and Astra xhigh turns.infoharksb-dotcom commentedon Oct 13, 2026
Additional Windows Codex Desktop report, October 14, 2026 (JST).
The app frequently stops with the following error after automatic reconnection reaches 5/5:
The screenshot of the failure shows “再接続中 5/5” (Reconnecting 5/5) and request ID
1685bc4b-a46b-4089-a807-be9de4458d36. Read-only inspection of the local session record confirms that exact request ended in a failedtask_completeevent.Environment checked locally:
26.1007.2314.0(Windows package metadata).0.162.0-alpha.17.2.gpt-6.1-sol; failures occurred with bothmaxandxhighreasoning.Three failed turns were found in the affected conversation:
7a682b0a-c867-4306-832f-583f8df1b1c31685bc4b-a46b-4089-a807-be9de4458d36d1a3b5e2-47a7-496b-a870-12c59614ea4dAll three terminal events contain the same request-processing/stream-disconnection message and
codex_error_info: "other". The model retry logs for this conversation show sequences reaching 5/5. The first sequence also logged “We’re currently experiencing high demand, which may cause temporary errors.”These failures interrupt ongoing work and recur when continuing the conversation.
The user additionally reports that switching to GPT-6 Luna and GPT-6 Astra also results in the same error. Switching models has not stopped the recurrence.
Please correlate the request IDs and timestamps with backend records, identify the failure, and provide a fix or a supported way to continue the affected conversation while preserving its history and completed work.
leishanshan8257-hash commentedon Oct 14, 2026
Additional Windows desktop occurrence — reported October 14, 2026 (UTC+08)
The affected user explicitly requested that this response-stream failure be reported.
User-provided error:
Environment verified locally: Windows desktop installation; installed OpenAI.Codex package version
26.1007.2314.0. This is Windows package metadata, not an independently verified About-dialog version.Impact: The user reports a request failing before completion, interrupting the ongoing workflow.
Evidence limits:
Please investigate the interrupted stream and provide a supported recovery/resume path that preserves the conversation and completed work. A request ID from this occurrence is available for private OpenAI Support correlation.
Submitted with AI assistance at the user's explicit request. No raw logs, prompts, screenshots, project data, credentials, or account/session identifiers are attached.
zelinq724 commentedon Oct 14, 2026
Recurring stream failures make ongoing Codex projects unusable
I have repeatedly encountered “stream disconnected before completion” across multiple separate projects and subsequent attempts to continue them. This is a recurring failure pattern, not an isolated interruption. It has become predictable enough that I cannot rely on a project remaining usable, even after it temporarily resumes.
The common characteristics of the affected workflow are long-running projects, GPT-6.1 Sol, and Ultra reasoning effort.
The documented incidents include:
Retrying, waiting, and creating forks have not produced a dependable resolution. Temporary continuation does not solve the problem when the same failure returns during actual work.
In the latest incident, the UI displayed “We’re currently experiencing high demand, which may cause temporary errors,” followed by repeated request-processing errors and final disconnection. Earlier diagnostics also recorded high-demand errors, exhausted WebSocket retries, HTTP fallback, and further failed retries. In one incident, the parent task failed and its Goal became blocked while both child tasks subsequently completed.
The practical impact is that I cannot use Codex reliably for these ongoing projects. I cannot keep spending hours on work that becomes unable to continue, then repeat recovery attempts without knowing when it will fail again. Until this recurring failure is resolved, this workflow is effectively unusable.
Please investigate the repeated failures and provide a concrete fix or a supported, dependable recovery procedure. Another briefly successful test is not sufficient; the projects need to remain usable during sustained work.
Detailed logs and request identifiers have already been supplied privately to Support. Earlier diagnostics recorded Windows package 26.1007.2314.0 and backend/CLI 0.162.0-alpha.17.2.
I have already provided Support with diagnostic logs, request IDs, screenshots, and a screen recording. Support has confirmed that no further evidence or lengthy reproduction is needed, but still cannot confirm whether an engineering team has been assigned, who owns the investigation, or when I will receive a substantive technical update. The case remains “In Progress” without a concrete resolution plan. I need this to reach a technical owner who can investigate and resolve the recurring failures.
Support case: #16910946.