[Windows][Codex App][Work] Remote context compaction fails at ~84% with "idle timeout waiting for SSE" even when Responses WebSocket is healthy

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.

Start by reproducing automatic remote compaction in a Windows Codex App Work thread at approximately 84–86% context usage, then compare the behavior with codex doctor --json confirming a successful WebSocket handshake. Investigate the reported SSE idle timeout and reconnect loop using the available desktop/app-server or session rollout logs; done means compaction completes, context usage decreases, and the Work thread continues without the timeout.