Windows desktop and CLI repeatedly disconnect HTTP/SSE streams with "error decoding response body" even with WebSockets disabled #49540

What issue are you seeing?

Codex repeatedly loses its response stream on Windows in both the desktop app and the CLI. Automatic retries reach 5/5, and manually asking it to continue can encounter the same failure again. This interrupts ongoing work and leaves the user uncertain about task completion.

stream disconnected before completion: Transport error: network error: error decoding response body

The CLI screenshot also shows:

Reconnecting... 3/5 (35m 21s • esc to interrupt)
└ Stream disconnected before completion: Transport error: network error: error decoding response body

WebSocket inference is explicitly disabled. The active provider is using HTTP/SSE, and local logs contain codex_api::sse::responses SSE Error. Disabling WebSockets has not eliminated the repeated disconnects. This report does not establish whether the root cause is Codex, the service, the proxy, or the corporate network.

Environment

• Windows 11 x64, version 10.0.26200.
• Desktop app package: 26.928.1915.0; bundled CLI/app-server binary: 0.159.0.
• Separately installed CLI: 0.159.2; managed app-server daemon release: 0.159.2.
• Model: gpt-6.1-sol, reasoning effort high.
• Authentication: ChatGPT sign-in, not an API key. Subscription tier not included.
• Network: corporate wired connection, Clash Verge Rev/Mihomo in rule mode, TUN enabled. Codex traffic is routed through a US proxy node.
• Proxy environment variables point to http://127.0.0.1:7897; Windows system proxy is disabled. TUN remains enabled, so a request with --noproxy '*' is not necessarily a direct Internet connection.

Active configuration

Relevant excerpt from the user-level config.toml:

model = "gpt-6.1-sol"
model_provider = "chatgpt-http"
model_reasoning_effort = "high"
model_auto_compact_token_limit = 697600
model_context_window = 872000

[model_providers.chatgpt-http]
name = "ChatGPT HTTP"
base_url = "https://chatgpt.com/backend-api/codex"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false
supports_standalone_web_search = true

There is no http profile in the inspected configuration. The provider is selected at the top level, and the inspected running Codex command lines do not override this provider setting. The doctor report independently confirms that the active provider has WebSockets disabled.

What steps can reproduce the bug?

Observed workflow, not a deterministic minimal reproduction:

1. Sign in with ChatGPT on Windows and use the HTTP provider configuration above.
2. Run an extended document analysis/editing task through the desktop app or CLI over the described proxy/corporate-network setup.
3. Let the task run. The response stream can fail with the error above, and Codex begins reconnecting.
4. Automatic retries can reach 5/5. Asking the desktop app to continue can fail again.

The original task text contains private business material and is omitted. The failure has been observed in multiple local conversations. Mobile-hotspot and independent-node A/B tests have not yet been completed.

Logs

Representative local log excerpts from 2026-09-30; timestamps below are UTC+08:00. Workspace paths, conversation IDs, and request IDs are omitted.

15:53:20 ERROR codex_models_manager::manager: failed to refresh available models: request timed out
16:04:04 WARN  codex_core::responses_retry: stream disconnected - retrying sampling request (5/5 in 3.477s)...
16:10:04 INFO  codex_core::session::turn: Turn error: stream disconnected before completion: Transport error: network error: error decoding response body
16:12:20 DEBUG codex_api::sse::responses: SSE Error: Transport error: network error: error decoding response body
16:17:18 DEBUG codex_api::sse::responses: SSE Error: Transport error: network error: error decoding response body
16:17:37 DEBUG codex_api::sse::responses: SSE Error: Transport error: network error: error decoding response body

Codex doctor report

codex doctor --json was run with CLI 0.159.2. This is a reviewed, abbreviated summary, not the full report:

{
  "schemaVersion": 1,
  "codexVersion": "0.159.2",
  "overallStatus": "warning",
  "checks": {
    "auth.credentials": {
      "status": "ok",
      "summary": "auth is configured"
    },
    "config.load": {
      "status": "ok",
      "model": "gpt-6.1-sol",
      "model provider": "chatgpt-http"
    },
    "network.provider_reachability": {
      "status": "warning",
      "summary": "desktop update and runtime CDN is unreachable",
      "inference URL probe": "reachable (HTTP 405)",
      "API route probe": "route exists (HTTP 401)",
      "desktop assets CDN": "persistent.oaistatic.com request timed out (optional)"
    },
    "network.websocket_reachability": {
      "status": "ok",
      "summary": "Responses WebSocket is not enabled for the active provider",
      "supports websockets": "false",
      "wire API": "responses"
    }
  }
}

Additional diagnostics and limitations

• Eight pings to the corporate LAN gateway returned approximately 1 ms each, with 0% packet loss. Physical Ethernet adapter error/drop counters were zero. This is a short LAN check and does not rule out upstream corporate-network problems.
• Unauthenticated requests to the Codex models endpoint returned HTTP 401 in about 1 second through both the explicit local HTTP proxy and the TUN path. These responses establish short-request reachability only; they do not validate authentication or long-running SSE stability.
• Proxy logs confirm that codex.exe traffic to chatgpt.com:443 uses the proxy node. Separate DNS-resolution warnings for OpenAI file/content domains were also present, but their relationship to this inference failure is unproven.
• No controlled WebSocket-versus-HTTP comparison, alternate-network comparison, or alternate-node comparison has been completed.

What is the expected behavior?

Tasks should complete reliably, or recover from transient stream interruptions without repeatedly exhausting reconnect attempts. If recovery fails, diagnostics should expose the underlying cause where available (for example, a timeout, connection reset, truncated body, decompression failure, or upstream status), instead of only the generic response-body decoding message. This would help distinguish client/service failures from proxy and corporate-network failures.

Related reports

Similar error text has been reported in #29087 and #23842. This report adds Windows desktop/CLI version details, an explicitly HTTP-only provider, local SSE log evidence, and proxy/TUN diagnostics; it does not assume those reports have the same root cause.