Repository navigation
[Windows][Codex App][Work] Remote context compaction fails at ~84% with "idle timeout waiting for SSE" even when Responses WebSocket is healthy #45472
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Codex App / ChatGPT Desktop: About dialog: 26.908.40834 MSIX package: OpenAI.Codex 26.908.4834.0 Bundled Codex CLI: codex-cli 0.154.0-alpha.6.2
What subscription do you have?
Plus
What platform is your computer?
Microsoft Windows NT 10.0.19045.0 x64
What issue are you seeing?
Remote context compaction in Codex App / Work repeatedly fails when the context window reaches approximately 84–86%.
The current failure is:
Error running remote compact task:
stream disconnected before completion:
idle timeout waiting for SSE
Immediately before the error, the UI shows that the conversation was compacted/optimized, then shows:
Reconnecting 2/2
and eventually the remote compact task fails.
This prevents long-running Work threads from continuing reliably once automatic context compaction is triggered.
Important transport isolation:
Initially, Codex Responses WebSocket connections from this Windows PC were receiving HTTP 403 Forbidden from:
wss://chatgpt.com/backend-api/codex/responses
I separately fixed that transport issue by explicitly routing Codex through a local HTTP proxy.
Current environment variables:
HTTP_PROXY=http://127.0.0.1:10809
HTTPS_PROXY=http://127.0.0.1:10809
http_proxy=http://127.0.0.1:10809
https_proxy=http://127.0.0.1:10809
After this change, codex doctor --json reports:
status: ok
summary: Responses WebSocket handshake succeeded
handshake result: HTTP 101 Switching Protocols
proxy env vars present: HTTP_PROXY, HTTPS_PROXY, http_proxy, https_proxy
Normal Work/model requests operate successfully through this configuration.
However, automatic remote context compaction still fails independently at approximately 84% context utilization with the SSE idle-timeout error above.
Therefore the original WebSocket 403 and the remaining remote-compaction failure appear to be separate issues.
The failure has also occurred on previous attempts with remote compaction. Before fixing the WebSocket transport, compaction failures included:
Transport error: network error: error decoding response body
and:
stream disconnected before completion:
idle timeout waiting for SSE
After the WebSocket path was confirmed healthy (HTTP 101), the SSE idle-timeout failure remained reproducible.
What steps can reproduce the bug?
Remote context compaction in Codex App / Work repeatedly fails when the context window reaches approximately 84–86%.
The current failure is:
Error running remote compact task:
stream disconnected before completion:
idle timeout waiting for SSE
Immediately before the error, the UI shows that the conversation was compacted/optimized, then shows:
Reconnecting 2/2
and eventually the remote compact task fails.
This prevents long-running Work threads from continuing reliably once automatic context compaction is triggered.
Important transport isolation:
Initially, Codex Responses WebSocket connections from this Windows PC were receiving HTTP 403 Forbidden from:
wss://chatgpt.com/backend-api/codex/responses
I separately fixed that transport issue by explicitly routing Codex through a local HTTP proxy.
Current environment variables:
HTTP_PROXY=http://127.0.0.1:10809
HTTPS_PROXY=http://127.0.0.1:10809
http_proxy=http://127.0.0.1:10809
https_proxy=http://127.0.0.1:10809
After this change, codex doctor --json reports:
status: ok
summary: Responses WebSocket handshake succeeded
handshake result: HTTP 101 Switching Protocols
proxy env vars present: HTTP_PROXY, HTTPS_PROXY, http_proxy, https_proxy
Normal Work/model requests operate successfully through this configuration.
However, automatic remote context compaction still fails independently at approximately 84% context utilization with the SSE idle-timeout error above.
Therefore the original WebSocket 403 and the remaining remote-compaction failure appear to be separate issues.
The failure has also occurred on previous attempts with remote compaction. Before fixing the WebSocket transport, compaction failures included:
Transport error: network error: error decoding response body
and:
stream disconnected before completion:
idle timeout waiting for SSE
After the WebSocket path was confirmed healthy (HTTP 101), the SSE idle-timeout failure remained reproducible.
What is the expected behavior?
When automatic compaction is triggered, the remote compact operation should complete successfully, the effective context usage should decrease, and the Work thread should continue without reconnect loops or SSE timeout errors.
If the server returns a terminal compaction error, Codex should surface the original server error immediately rather than eventually reporting only "idle timeout waiting for SSE".
Additional information
This has been investigated extensively as a local networking issue.
Already tested / ruled out as the primary cause:
- Windows Firewall
- WinHTTP proxy configuration
- WinINET proxy configuration
- hosts file
- Radmin VPN adapter/service
- Happ service on/off
- Winsock entries
- Npcap filter
- Microsoft Network Monitor filter
- NDIS lightweight filter
- authentication refresh / logout-login
- direct network route
- bundled Codex CLI update
The original Responses WebSocket HTTP 403 problem was successfully isolated and fixed using an explicit HTTP proxy. After the fix, codex doctor consistently receives HTTP 101 Switching Protocols.
The remote-compaction SSE failure persists after that fix.
The failure is not related to the project data being processed: normal Work turns before the automatic-compaction threshold complete successfully.
Latest affected session ID:
Not available in the Desktop logs currently being written on this installation.
Context usage at reproduction:
approximately 84%
Previous affected conversation IDs with thread/compact/start accepted successfully:
01a09e25-546d-7a50-acb8-f86e1dbe2d6e
01a09e50-1aac-7860-ac55-81432fb28d6f
01a07d48-8d71-7301-8a7a-9accec93d0a4
I can provide additional desktop/app-server logs or session rollout logs if needed.
Please let me know if there is a specific diagnostic flag or log category that would help capture the server-side response preceding the SSE idle timeout.
Activity
github-actions commentedon Sep 14, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
HomageSxGod commentedon Sep 16, 2026
Reproduced on a second Windows computer with the same Codex Desktop build. This is a separate local installation and a separate local conversation. Reinstalling the application on the original PC did not resolve the issue.
mrstepanrf-a11y commentedon Sep 26, 2026
Fresh Windows reproduction on 2026-09-26 with a newer Codex Desktop/runtime, adding sanitized timing + request IDs for backend correlation.
Environment:
Observed sequence (UTC):
IO error: cannot decrypt peer's messagefalling back to HTTPidle timeout waiting for SSEThe observed 200 -> SSE idle-timeout interval is ~302.356 s.
Request IDs for OpenAI-side correlation:
b97aa370-823a-4870-889e-7e1edcbe0484(200 at 07:05:08.033056 UTC; timeout later at 07:10:10.389050)d0296b34-7715-4ea4-96bb-46cc1efff613(retry 200 at 07:10:12.243484 UTC)Additional local evidence:
cannot decrypt peer's messagesignature was also observed in a preceding non-compaction sampling turn, so there may be a separate transport symptom as well.This looks very close to this issue, with an additional possible interaction with #43140: after HTTP 200, the client ultimately exposes only the ~300 s SSE idle timeout. I cannot prove a terminal
response.failedwas received in this production incident.Could maintainers correlate the two request IDs above and confirm whether the compaction backend emitted a terminal event, continued emitting stream events, or stalled after headers? That would distinguish an upstream compaction failure from loss/stall between backend and client.
xiamuliangtai commentedon Sep 27, 2026
Additional reproduction report (2026-09-27, UTC+8):
I am seeing the same automatic remote-compaction failure pattern across multiple long-running ChatGPT Work / Codex threads.
Reproduction pattern:
Error running remote compact task: stream disconnected before completion: Incomplete response returned, reason: content_filterError running remote compact task: stream disconnected before completion: error sending requestReconnecting 2/2.The common trigger appears to be automatic context compaction around the ~85% context-usage point, rather than the underlying project contents. This is especially disruptive because the affected Work/Codex threads contain long-running project history that users cannot simply discard.
Please investigate whether the remote compaction path can fail at the auto-compaction threshold and leave saved threads stuck in a retry/failure state. A recovery mechanism for already-affected threads (retry compaction safely, rebuild compacted context, or resume without losing the existing thread) would also be very valuable.
Mianhuatang666 commentedon Oct 10, 2026
I encountered a similar issue on October 10, 2026: a task in Codex Work got stuck during context compaction, and all chats in my Work folders became unusable.
The error was:
The UI also showed reconnect attempts, such as
Reconnecting 2/2.I haven't confirmed the root cause, but I'd like to share what I observed and what restored access in my case.
Possible cause
Around noon, I noticed that I could no longer access the ChatGPT website through my Clash proxy. At the same time, the ongoing Work task was stuck during compaction and showing the errors above. After restarting Codex, I could no longer access it either.
This led me to suspect a proxy connectivity issue. My proxy provider's dashboard was also inaccessible, and the provider had posted an announcement that all of its Japan nodes were unavailable.
What worked for me
I switched to a different proxy provider. However, the new proxy setup used a different local port. I already had configuration tied to the old port to address repeated GPT reconnections, so I:
After switching providers and reusing the original local proxy port, Codex Work became usable again.
This resolved the problem in my environment, but I can't confirm whether it shares the same underlying cause as the compaction failure reported here.