[버그] Codex App 연동 시 WebSocket 비활성 프록시가 HTTP 426을 반환합니다 #324

Activity

1. lidge-jun commented on Jul 23, 2026

   

   lidge-jun

   on Jul 23, 2026 – with ChatGPT Codex Connector

   Owner

   More actions

   This is intended behavior in the current design, though the UX could be clearer.

   Why the 426 happens:

   OpenCodex defaults to websockets: false. When the Codex App or runtime attempts a Responses WebSocket connection, the proxy correctly rejects it with HTTP 426 Upgrade Required. The Codex client is expected to fall back to HTTP streaming, which works through the proxy without issues.

   Is functionality blocked?

   The critical question is whether the 426 actually prevents the Codex App from working, or whether it's only a codex doctor warning:

   • If Codex App falls back to HTTP and works normally, this is a cosmetic diagnostic warning. The codex doctor output could be improved to explain that a local proxy with websockets: false is expected to return 426 and that HTTP fallback is the normal path.
   • If specific features (streaming resumption, reconnection) require WebSocket and fail without fallback, the fix is "websockets": true in your OpenCodex config.

   Recommendation:

   1. Try adding "websockets": true to your OpenCodex config and verify whether it resolves the doctor warning.
   2. If the App works fine despite the 426, this is a docs/doctor-message improvement rather than a proxy bug.

   Could you confirm whether actual Codex App functionality is broken (requests fail, streaming stops) or whether this is only the codex doctor diagnostic showing a warning?
2. jhste102lab commented on Jul 23, 2026

   

   jhste102lab

   on Jul 23, 2026 – with ChatGPT Codex Connector

   ContributorAuthor

   More actions

   Thanks for the clarification. I rechecked the evidence and agree that, in my current environment, the HTTP 426 appears to be a codex doctor diagnostic rather than a demonstrated functionality failure.

   • I do not currently have a reproducible Codex App request failure, stream termination, or reconnection failure attributable to the WebSocket warning.
   • Valid Codex App tasks continued to run while the warning was present, so I cannot claim that websockets: false caused the observed task-resume symptom.
   • The no rollout found symptom I initially investigated is separate: the Codex Desktop log shows In-App Browser session IDs being passed to thread/resume as remote-SSH thread IDs. I reported that separately in openai/codex#34894.

   I have not changed the setting to "websockets": true, because I do not currently have an actual App failure against which to validate it.

   Please treat this issue as a documentation/diagnostic-UX suggestion rather than a confirmed proxy defect: it would help if the integration documentation and/or diagnostic output explained that HTTP 426 is expected when OpenCodex intentionally uses HTTP streaming fallback. Thank you.
3. lidge-jun

   added a commit that references this issue on Jul 23, 2026

   docs: add roadmap for untouched issue sweep (WP0)

   ...

   1bc69e0
4. lidge-jun commented on Jul 23, 2026

   

   lidge-jun

   on Jul 23, 2026

   Owner

   More actions

   Closing as documentation-covered, per the discussion above and a fresh docs check.

   As established: HTTP 426 from a proxy with websockets: false is the intended design — the Codex client falls back to HTTP/SSE streaming and no functionality is lost. You confirmed no reproducible App failure was attributable to the warning.

   The current documentation now covers this explicitly:

   • the Codex App models guide explains that a disabled-WebSocket proxy returns 426 and that HTTP/SSE fallback is the normal path;
   • the architecture reference documents the 426 upgrade-rejection behavior.

   The clearer codex doctor wording suggestion is an upstream (openai/codex) diagnostic-UX improvement rather than an OpenCodex change — your separate upstream report is the right channel for that. Thanks for the careful investigation and for narrowing this to the diagnostic surface.
5. lidge-jun

   closed this as not plannedon Jul 23, 2026
6. agentHits

   added a commit that references this issue on Sep 17, 2026

   docs: add roadmap for untouched issue sweep (WP0)

   ...

   5bb63ab