[Bug]: Long Codex thread fails only through OpenCodex proxy (WS 1006 / response prelude timeout); bypass works immediately

[mehmeemow]

Client or integration

Codex App (also reproduced from Codex CLI when resuming the same problematic thread).

Area

Streaming

Summary

A long-running Codex conversation became effectively unusable only while traffic was routed through OpenCodex. The same account, model, machine, repository and thread work normally again as soon as the OpenCodex proxy is disabled/bypassed.

This does not look like a generic network outage because the failure is both thread-specific and proxy-path-specific.

With OpenCodex enabled, the problematic parent thread repeatedly failed with either:

stream disconnected before completion:
Upstream stream terminated unexpectedly:
codex websocket closed before a Responses terminal event
(close 1006 Connection ended)

or:

stream disconnected before completion:
Upstream stream terminated unexpectedly:
codex websocket response prelude timed out

After OpenCodex was disabled/bypassed, the same existing thread resumed and worked normally immediately, without fork, rollback, or compaction recovery.

Expected behavior: OpenCodex should transparently proxy the same Codex Responses request, or safely fall back to HTTP/SSE when the upstream WebSocket path cannot complete.

This appears related to one or more WebSocket relay edge cases such as large replay payloads, loss of upstream close code/reason, the response-prelude timeout, or lack of safe HTTP/SSE fallback after an already-open WebSocket terminates.

Related issues:

• [Bug] Codex WS upstream: any request >=16 MiB dies as 502 upstream_server_error, with no SSE fallback #2471 — large Codex WS upstream request / 16 MiB boundary, missing SSE fallback, close code/reason loss.
• Codex WebSocket 的 30 秒响应开始上限会截断正常的多图慢请求 #4083 — fixed response-prelude timeout can truncate legitimate slow-start Responses requests.
• Make the Codex WebSocket response prelude timeout configurable #3976 — request to make the response-prelude timeout configurable.

This report adds a real-world A/B observation: the exact same previously failing thread becomes healthy immediately when OpenCodex is bypassed.

Reproduction

1. Run Codex Desktop on Windows with Codex traffic routed through OpenCodex to the normal ChatGPT/Codex upstream.
2. Open/resume an existing long-running conversation.
3. Observe repeated stream disconnected before completion failures for many hours.
4. Switch the host network to a mobile hotspot. Observe the same failure.
5. On the same machine, start Codex CLI and create a fresh conversation. The fresh conversation replies normally (Hello!).
6. In Codex CLI, resume the same problematic existing conversation. The failure reproduces.
7. While the parent conversation is failing, previously spawned sub-agents can continue executing normally.
8. Observe one or both of the errors shown in the Logs section below.
9. Disable/bypass OpenCodex without otherwise changing the account, model, repository, machine, or conversation.
10. Resume the same existing problematic thread again.
11. The thread now works normally.

A/B matrix:

Test	Result
Codex Desktop + OpenCodex + existing long thread	❌ stream disconnected
Same path on mobile hotspot	❌ same failure
Codex CLI + OpenCodex + fresh thread	✅ normal reply
Codex CLI + OpenCodex + same existing long thread	❌ stream disconnected
Sub-agents under the problematic conversation	✅ continued executing
Same existing long thread with OpenCodex bypassed	✅ works normally

Suggested diagnostics for reproducing this in OpenCodex:

• log serialized first-message/request size in bytes;
• preserve/log the actual upstream WebSocket close code and reason;
• log elapsed time from send() to quota/metadata control events and to the first non-control Responses event such as response.created;
• record whether any downstream Responses bytes/events were emitted before failure;
• record whether the exchange was eligible for a safe HTTP/SSE fallback.

Potential mitigations:

1. Preserve and expose the real upstream WS close code/reason instead of collapsing it into a generic downstream 1006-style failure.
2. Preflight large initial WS payloads and route to HTTP/SSE before opening WS when near the upstream size limit.
3. If WS opens but closes/times out before any real Responses event is delivered downstream, use HTTP/SSE fallback where it is safe and cannot duplicate inference.
4. Revisit or make configurable the response-prelude deadline for large/slow requests.

Version

OpenCodex v2.49.0

Codex Desktop 26.903.61454

Operating system

Windows 11

Provider and model

Canonical ChatGPT/Codex authenticated upstream. Exact model identifier was not captured as part of the initial incident.

Logs or error output

stream disconnected before completion:
Upstream stream terminated unexpectedly:
codex websocket closed before a Responses terminal event
(close 1006 Connection ended)

and later:

stream disconnected before completion:
Upstream stream terminated unexpectedly:
codex websocket response prelude timed out

Screenshots and supporting files

No private conversation content, repository content, credentials, or account identifiers are attached.

The strongest supporting evidence is the A/B result: the same existing long thread fails through OpenCodex and immediately succeeds when OpenCodex is bypassed.

Redacted configuration

{
  "client": "Codex Desktop / Codex CLI",
  "proxy_path": "Codex -> local OpenCodex -> canonical ChatGPT/Codex upstream",
  "control_test": "Codex -> canonical ChatGPT/Codex upstream (OpenCodex bypassed)",
  "result_with_proxy": "stream disconnected",
  "result_without_proxy": "same thread works normally"
}

No tokens, account identifiers, request credentials, private conversation text, or repository contents are included.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[lidge-jun]

리뷰 · 우선순위 74 / 80

설명

이 이슈는 “긴 Codex 대화가 OpenCodex 프록시를 거칠 때만 깨지고, 같은 계정·모델·머신·저장소·스레드에서 프록시를 끄면 바로 정상”이라는 A/B 관측입니다. 데스크톱이든 CLI든, 문제 있는 기존 스레드만 실패하고 새 스레드는 됩니다. 에러 문구도 리포에 있는 실제 문자열과 맞습니다. 하나는 codex websocket closed before a Responses terminal event (close 1006 Connection ended)이고, 다른 하나는 codex websocket response prelude timed out입니다.

지금 dev HEAD(12c248f52, package 2.50.0)의 Codex 업스트림 WebSocket 경로는 이렇게 동작합니다. src/server/responses/fetch-helpers.ts의 providerFetch가 ChatGPT-family 스트리밍을 codexWsUpstreamFetch로 태우고, 업그레이드 전·전송 실패 전에는 HTTP SSE로 넘어갈 수 있습니다. 하지만 이미 ws.send(frameText)가 성공한 뒤에는 src/server/responses/codex-ws-exchange.ts의 failStream이 바디 실패로 끝내며 SSE로 다시 보내지 않습니다. 이유는 주석에 적혀 있습니다. 업스트림에서 이미 턴이 시작됐을 수 있어서, 재전송하면 추론이 두 번 돌 수 있기 때문입니다.

관련으로 닫힌 이슈도 있습니다. #2471은 16 MiB create-frame 경계와 SSE 폴백을 다뤘고, src/server/responses/codex-ws-wire.ts에 MAX_CODEX_WS_CREATE_FRAME_BYTES와 codexWsCreateFrameExceedsLimit가 남아 있습니다. #4083/#3976은 response-prelude 타임아웃을 다루었고, 현재 상수는 CODEX_WS_RESPONSE_PRELUDE_TIMEOUT_MS = 90_000입니다(예전 30초보다 깁니다). close code도 closedBeforeTerminalMessage가 메시지에 붙입니다. 그런데도 이 리포트는 “프록시 ON이면 장시간 실패, OFF면 같은 스레드가 즉시 회복”이라서, 이미 머지된 완화만으로는 설명이 안 끝나는 실사용 회귀/잔여 구멍으로 보입니다. 긴 스레드는 create-frame이 커지고, 프록시 경로의 WS만 그 크기를 타고, 업스트림이 조용히 끊거나(1006) prelude 안에 의미 있는 Responses 이벤트가 안 오면 클라이언트가 반복 실패하는 그림과 잘 맞습니다.

라인 레벨로 보면 지금 코드는 “진단·프리플라이트”는 있고 “이미 연 WS가 prelude/조기 close로 죽으면 안전한 SSE 폴백”은 아직 없습니다. 리포터 제안(첫 메시지 바이트 로그, close code/reason 보존, send→첫 Responses 이벤트 경과 시간, 다운스트림 바이트 유무, SSE 폴백 자격)은 재현 없이도 다음 패치의 측정 축이 됩니다.

src/server/responses/codex-ws-exchange.ts 라인 214 - prelude 타이머가 만료되면 failStream("codex websocket response prelude timed out")만 하고 SSE로 내려가지 않는다. 리포트의 두 번째 에러와 정확히 같은 문자열이다.
src/server/responses/codex-ws-exchange.ts 라인 138-146 - failStream은 이미 sent면 200 바디 실패로 고정한다. 이중 추론을 막으려는 설계지만, “Responses 이벤트가 한 번도 안 나간 조기 실패”와 “이미 일부 이벤트를 보낸 실패”를 같은 길로 묶는다.
src/server/responses/codex-ws-wire.ts 라인 5 - prelude 한도는 지금 90초 고정이다. #3976은 닫혔지만 설정으로 늘리는 스위치는 이 HEAD 스냅샷만으로는 보이지 않는다.
src/server/responses/codex-ws-wire.ts 라인 115-125 - close code/reason은 메시지 문자열에는 붙지만, 주석대로 request log의 타입 코드로는 안 남는다. 장시간 현장 디버깅이 어렵다.
src/server/responses/codex-ws-wire.ts 라인 137-144 - create-frame이 한도 이상이면 SSE로 보내도록 프리플라이트가 있다. 한도 바로 아래의 긴 스레드(리플레이·스크린샷 누적)는 여전히 WS를 타고, 그때의 조기 close/prelude 실패는 폴백이 없다.

메인테이너의 판단이 필요한 지점

• “아직 Responses 이벤트가 하나도 다운스트림으로 안 나간 상태”에서만 SSE 폴백을 허용할지, 아니면 이중 추론 위험 때문에 WS 실패는 항상 바디 실패로 둘지.
• prelude 90초를 더 늘리거나 설정화할지, 아니면 긴 스레드는 create-frame 크기/예상 TTFT로 WS 자격을 더 좁힐지.
• 이 이슈를 #2471/#4083 후속 측정 이슈로 두고 재현 로그(프레임 바이트, close code, prelude 경과)를 필수 재현 조건으로 요구할지.
• Windows Codex Desktop 2.49.0 사용자 경로와 dev 2.50.0 HEAD의 동작 차이를 릴리즈 노트에 따로 적을지.

너의 추천
열어 두고 streaming 우선순위로 둔다. 첫 패치는 관측부터다. create-frame 바이트, close code/reason, send부터 첫 non-control Responses 이벤트까지 시간, 다운스트림 바이트 유무를 로그에 남긴 뒤, “sent지만 아직 responseCommitted/다운스트림 이벤트가 없는 조기 실패”만 안전한 HTTP SSE 폴백 후보로 설계한다. 설정 없는 90초 고정만 더 늘리는 것은 재현 없이 하지 말자. 중복 이슈로 닫지 말고 #2471/#4083/#3976을 Related로 링크한 채 잔여 구멍으로 추적한다.

이 댓글은 grok-bot이 작성했습니다

[Ingwannu]

One important constraint on the proposed fallback: at dev 6d3ad12, codex-ws-exchange.ts::failStream deliberately treats a successfully sent create frame as possibly executing upstream. No downstream Responses event yet is not proof the upstream did not accept or execute it. Please do not enable an automatic HTTP resend based only on responseCommitted === false or zero downstream bytes; that can duplicate the turn.

The A/B report is worth keeping open. The next useful evidence is content-free stage information: create-frame byte count, whether send completed, close code, and elapsed time to the first meaningful event, plus exact OCX/client versions. Do not attach conversation bodies, authorization headers, cookies, or raw close reasons containing request content. Preserve the current no-replay-after-send contract unless the upstream provides affirmative non-execution/idempotency evidence.