›_ Codex Issues
Codex Issues / #37661

[Windows][CLI 0.147.0] Interactive responses disconnect after WebSocket-to-HTTPS fallback despite clean doctor report

Open 💬 3 comments Opened Aug 9, 2026 by panixakira
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

Codex CLI 0.147.0 (npm installation, windows-x86_64)

What subscription do you have?

Not captured in the uploaded report.

Which model were you using?

gpt-5.6-sol (default fast)

What platform is your computer?

Windows x64

What terminal emulator and version are you using (if applicable)?

PowerShell; terminal emulator/version was not identified by codex doctor.

Codex doctor report

Codex Doctor v0.147.0 · windows-x86_64

Environment
✓ system       ja-JP
✓ runtime      npm
✓ install      consistent
✓ search       file exists (bundled)
✓ git          git version 2.55.0.windows.3
✓ terminal     unknown
✓ title        default
✓ state        databases healthy
✓ threads      rollout files and state DB thread inventory agree

Configuration
✓ config       loaded
✓ auth         auth is configured
✓ mcp          no MCP servers configured
✓ sandbox      restricted fs + restricted network · approval OnRequest

Updates
✓ updates      update configuration is locally consistent

Connectivity
✓ network      no proxy env vars
✓ websocket    connected (HTTP 101 Switching Protocols) · 15s timeout
✓ reachability active provider endpoints are reachable over HTTP

Background Server
○ app-server   not running (ephemeral mode)

17 ok · 1 idle · 0 warn · 0 fail

What issue are you seeing?

Interactive Codex CLI turns repeatedly fail with:

Falling back from WebSockets to HTTPS transport. stream disconnected before completion: An error occurred while processing your request.

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

The WebSocket connection initially works according to codex doctor (HTTP 101), but during an interactive turn the response stream disconnects. Codex falls back to HTTPS, and the HTTPS stream also disconnects before completion.

This reproduces in both resumed and brand-new interactive sessions. After a failure, even a short follow-up prompt can immediately fail the same way. By contrast, a short non-interactive control succeeds:

codex exec --skip-git-repo-check "ファイル操作をせず、OKだけ返してください。"

It returns OK.

A representative long turn had completed a Blender background probe and printed its output before the Codex response stream disconnected. The Blender warning shown immediately before the disconnect was non-fatal; the external command had already returned output.

What steps can reproduce the bug?

  1. On Windows x64 with Codex CLI 0.147.0, run codex.
  2. Use gpt-5.6-sol and submit a tool-using task that runs for longer than a trivial codex exec request.
  3. Observe tool output being returned.
  4. Observe Codex report WebSocket disconnection and fallback to HTTPS.
  5. Observe HTTPS also terminate with stream disconnected before completion.
  6. Send a short follow-up in the same session; it may fail immediately with the same error.
  7. Start a brand-new interactive session and repeat; the problem is not limited to resume --last.
  8. Run codex doctor --summary --no-color; it reports 17 ok, 0 warn, 0 fail, successful WebSocket HTTP 101, and provider HTTP reachability.
  9. Run the short codex exec --skip-git-repo-check control above; it succeeds.

Uploaded diagnostic thread ID:

019fe481-2bc5-75d0-a162-c337f46b33af

Representative request IDs:

  • 456005d3-7301-4e76-b2f9-2cc1d6786b8b
  • 20fc471e-8675-4039-b275-c39158a3d4f6
  • 0eeb88d5-6b6f-42f6-8a05-269a6e990d2d
  • 26d34e63-2ed4-4a25-9d73-bca8488533e6

What is the expected behavior?

If the WebSocket response stream disconnects, HTTPS fallback should continue and complete the turn. If both transports fail, Codex should expose a specific transport/server error and preserve enough state to retry without repeatedly losing the turn.

Additional information

Potentially related, but not identical:

  • #37649 reports frequent reconnect errors on Codex CLI 0.147.0, apparently on macOS.
  • #37089 reports Windows WebSocket/HTTPS failures, but its doctor report shows provider reachability and WebSocket checks failing. In this report, all doctor connectivity checks pass.
  • #24550 concerns large inline images retained in compacted history. This report also reproduces in a brand-new interactive session, so it is not limited to resuming one compacted thread.

The CLI /feedback upload completed successfully before the next interactive response disconnected.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 19 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #37649
  • #37089
  • #37647
  • #37652

Powered by Codex Action

s35indy-pixel · 19 days ago

I can reproduce the same failure pattern on another Windows machine, with a clean current doctor report.

Environment:

  • Codex CLI currently: 0.147.0, npm, windows-x86_64
  • OS: Windows 11 Professional, 10.0.26200, zh-TW
  • Terminal: Windows Terminal / PowerShell
  • Model: gpt-5.6-sol
  • ChatGPT Plus auth
  • No proxy environment variables
  • codex doctor: 17 ok, 1 idle, 0 warn, 0 fail; WebSocket HTTP 101; provider endpoints reachable

Affected thread:

  • Thread/session ID: 019fc2b4-e608-7d21-a9a3-11f929016b7c
  • This long-running thread was originally created with CLI 0.146.0 and later resumed after updating to 0.147.0.
  • The thread included many ordinary text/image turns and local tool calls. It became repeatedly unable to complete even short follow-up turns.
  • Starting a separate fresh Codex session currently works, so this instance may have a thread-specific component.

Eight failures were recorded on 2026-08-09 between 08:55 and 11:47 Asia/Taipei. All were logged as codex_error_info: "other" with last_agent_message: null and stream disconnected before completion:

  • 3a00c368-6d84-4c5d-b380-d89966a53a5d
  • aec4ad98-e7d0-4ef5-9fba-937c235c5f01
  • 1b60eb43-15bb-498b-aa4e-237e0e2d8abf
  • c16d7ef0-1a4a-48a1-9d88-ad897145c1da
  • ba21acd5-5d65-4de3-86be-b1b27498ba58
  • 3a0f48cf-0989-42c2-8f07-c17a176619d8
  • 5d087bd1-831b-4f2e-8eda-8537434e0305
  • 9dd4250a-6e1e-4ae7-918b-65921772324a

Individual failed turns ran for approximately 123–272 seconds before termination. The local state/thread databases pass all integrity checks.

This appears consistent with the report here, but the old-thread-created-on-0.146.0/resumed-on-0.147.0 detail may be useful when investigating compatibility or recovery behavior. I can provide additional redacted rollout excerpts if maintainers request them.

Fiazul · 17 days ago

I can reproduce what appears to be the same failure on Linux/Ubuntu with Codex CLI 0.147.0 and gpt-5.6-sol, so this does not appear to be Windows-specific.

Environment:

  • Ubuntu 22.04 x86_64
  • Codex CLI 0.147.0 standalone
  • ChatGPT Plus authentication
  • Model: gpt-5.6-sol
  • No proxy environment variables
  • UFW inactive
  • No MCP servers configured

The failure happens during normal long-running, tool-heavy development sessions. Codex works normally for a while, including reading files, editing code, running tests, inspecting images, etc., and then I get:

WebSocket protocol error: Connection reset without closing handshake

along with:

Falling back from WebSockets to HTTPS transport

and:

stream disconnected before completion

The important part is that the active turn does not successfully recover/continue after the HTTPS fallback.

I have reproduced this across both resumed sessions and fresh Codex sessions.

My diagnostics are also a little unusual.

codex doctor --json reports the Responses WebSocket handshake as successful:

network.websocket_reachability: ok

handshake result: HTTP 101 Switching Protocols

supports websockets: true

The same doctor report shows:

  • authentication: OK
  • config: OK
  • installation: OK
  • MCP config: OK
  • proxy env vars: none
  • state databases/integrity: OK
  • WebSocket handshake: OK

However, the separate provider reachability check fails:

ChatGPT base URL: https://chatgpt.com/backend-api/ request timed out (required)

That check takes approximately 3.1 seconds before failing.

I tested the same endpoint directly from the same machine and shell:

curl -4 -sS -o /dev/null -w 'HTTP=%{http_code} DNS=%{time_namelookup}s CONNECT=%{time_connect}s TLS=%{time_appconnect}s START=%{time_starttransfer}s TOTAL=%{time_total}s\n' --max-time 15 https://chatgpt.com/backend-api/

Result:

HTTP=403 DNS=0.002118s CONNECT=0.004753s TLS=0.061247s START=0.069227s TOTAL=0.069391s

The unauthenticated 403 is expected; the relevant point is that DNS/TCP/TLS/HTTP connectivity completes in about 69 ms from the same machine.

I also checked the available Codex feature flags:

responses_websockets removed false

responses_websockets_v2 removed false

So I have not found a supported way in CLI 0.147.0 to force the built-in OpenAI provider to avoid the WebSocket transport for testing.

Affected sessions include:

  • 019fef1b-5fc5-7682-a71e-7f57d1a08f4a
  • 019fef9a-6966-78e2-8005-ebfbd48218f7

Uploaded diagnostic thread:

  • 019fefa7-43f3-71f3-a081-77348b3987b7

Representative request IDs from interrupted runs:

  • d947b243-6cb0-4ad3-ab24-6c748a44b3db
  • a2326c97-2dad-431a-92fa-37bedadf84cb
  • 9e5b8b99-197b-4f47-aa1e-e546fa22882e
  • 27836a24-c4d5-41eb-8948-63da7c47c331

From my side, the main issue is not simply that a WebSocket can occasionally disconnect. The problem is that Codex explicitly announces a fallback from WebSockets to HTTPS, but the active agent turn does not reliably recover after that fallback.

This makes sustained Codex CLI development sessions unreliable on Linux as well, especially for longer tasks involving many tool calls.