Repository navigation
[버그] Codex App 연동 시 WebSocket 비활성 프록시가 HTTP 426을 반환합니다 #324
Description
요약
OpenCodex를 실행하면 Codex 설정에 로컬 프록시 주소가 자동 주입됩니다.
openai_base_url = "http://127.0.0.1:10100/v1"그런데 현재 OpenCodex 설정에서 websockets가 false여서, Codex App/Codex 런타임이 Responses WebSocket 연결을 시도할 때 아래 오류가 발생합니다.
HTTP 426 Upgrade Required
{"error":{"message":"Responses WebSocket transport is disabled; use HTTP"}}
Codex 진단에서는 WebSocket 연결 실패 및 HTTPS fallback 가능 상태로 표시됩니다. 프록시가 자동으로 주입되는 기본 구성이라면, Codex App에서 스트리밍·재개 등 WebSocket 경로가 필요한 기능과 호환되지 않을 가능성이 있습니다.
재현 절차
- OpenCodex를 설치하고 실행합니다. (
ocx start또는 자동 시작) - OpenCodex가 Codex 전역 설정에
openai_base_url = "http://127.0.0.1:10100/v1"을 주입한 상태를 확인합니다. - OpenCodex 설정에서
websockets: false상태로 Codex App 또는 Codex 런타임을 실행합니다. - Codex 진단을 실행합니다.
codex doctor --all- 다음과 유사한 WebSocket 오류가 표시됩니다.
Responses WebSocket failed
HTTP 426 Upgrade Required:
Responses WebSocket transport is disabled; use HTTP
기대 동작
다음 중 하나가 필요합니다.
- Codex App 연동 시 OpenCodex가 호환되는 WebSocket transport를 제공한다.
- WebSocket이 비활성화된 경우, Codex에 이를 명시해 HTTP transport만 사용하도록 안전하게 구성한다.
- WebSocket이 필요한 Codex App 기능이 제한될 수 있음을 자동 주입 과정 및 문서에서 명확히 알린다.
현재처럼 프록시 주소만 자동 주입되고 WebSocket 요청이 426으로 실패하면, 사용자는 Codex App의 연결/재개 문제로 오해하기 쉽습니다.
환경
- OpenCodex:
2.7.33 - Codex App:
26.715.10079.0 - OS: Windows 11 (10.0.22000, x64)
- WSL: Ubuntu 24.04
- Provider/model: 해당 없음
확인 사항
- 기존 이슈와 문서를 검색했습니다.
- 토큰, 계정 정보, 인증 정보, 개인 정보는 포함하지 않았습니다.
Activity
lidge-jun commentedon Jul 23, 2026
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 doctorwarning:codex doctoroutput could be improved to explain that a local proxy withwebsockets: falseis expected to return 426 and that HTTP fallback is the normal path."websockets": truein your OpenCodex config.Recommendation:
"websockets": trueto your OpenCodex config and verify whether it resolves the doctor warning.Could you confirm whether actual Codex App functionality is broken (requests fail, streaming stops) or whether this is only the
codex doctordiagnostic showing a warning?jhste102lab commentedon Jul 23, 2026
Thanks for the clarification. I rechecked the evidence and agree that, in my current environment, the HTTP 426 appears to be a
codex doctordiagnostic rather than a demonstrated functionality failure.websockets: falsecaused the observed task-resume symptom.no rollout foundsymptom I initially investigated is separate: the Codex Desktop log shows In-App Browser session IDs being passed tothread/resumeas 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.
docs: add roadmap for untouched issue sweep (WP0)
lidge-jun commentedon Jul 23, 2026
Closing as documentation-covered, per the discussion above and a fresh docs check.
As established: HTTP 426 from a proxy with
websockets: falseis 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 clearer
codex doctorwording 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.docs: add roadmap for untouched issue sweep (WP0)