Skip to content

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

Open
Open
[Windows][CLI 0.147.0] Interactive responses disconnect after WebSocket-to-HTTPS fallback despite clean doctor report#37661
Labels
CLIIssues related to the Codex CLIbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)windows-osIssues related to Codex on Windows systems

Description

@panixakira
panixakira
opened on Aug 9, 2026

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:

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

Activity

  1. github-actions
    added
    bugSomething isn't working
    CLIIssues related to the Codex CLI
    windows-osIssues related to Codex on Windows systems
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on Aug 9, 2026

  2. github-actions commented on Aug 9, 2026

    @github-actions
    github-actionsbot
    on Aug 9, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. s35indy-pixel commented on Aug 9, 2026

    @s35indy-pixel
    s35indy-pixel
    on Aug 9, 2026 – with ChatGPT Codex Connector

    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.

  4. Fiazul commented on Aug 11, 2026

    @Fiazul
    Fiazul
    on Aug 11, 2026

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CLIIssues related to the Codex CLIbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)windows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions