[Bug][Codex App] Large canonical Responses requests fail after v2.31.0 enables upstream WebSocket

[simon1561]

Client or integration

Codex App

Area

Streaming

Summary

After upgrading from OpenCodex v2.28.0 to v2.31.0, one existing long-running Codex App task consistently fails through the canonical ChatGPT Responses route.

The request is approximately 18.2 MB as JSON. On v2.28.0, the same task and essentially the same request size completed successfully over the HTTP/SSE upstream path. On v2.31.0, the request is routed through the upstream Codex WebSocket and fails before any terminal Responses event:

Upstream stream terminated unexpectedly: codex websocket closed before a Responses terminal event

OpenCodex records status 502. I expected either the WebSocket path to complete successfully or OpenCodex to choose HTTP/SSE before opening the WebSocket when the outbound request is too large for the WS path.

Reproduction

1. Run OpenCodex v2.31.0 with its bundled Bun 1.4.0.
2. Use Codex App with the main ChatGPT account and the canonical ChatGPT Responses endpoint.
3. Resume an existing tool-heavy task whose streaming /responses request body is approximately 18.2 MB.
4. Send a short message.
5. Codex App retries 5 times. Each upstream attempt closes before a terminal Responses event and OpenCodex returns 502.

Control observation:

• OpenCodex v2.28.0 bundled Bun 1.3.14.
• The same task, model, account, and approximately 18.2 MB request completed with HTTP 200 over HTTP/SSE.
• The successful request was approximately 18,200,828 bytes before compression and 11,513,677 bytes after zstd.
• After v2.31.0 starts with Bun 1.4.0, requests of approximately 18,197,133 bytes consistently fail on the upstream WebSocket path.
• Other shorter conversations using the same account and model still succeed on v2.31.0, so the failure appears request-size/task-state specific rather than a general account, model, or network outage.
• Setting websockets: false only disables the inbound Desktop-to-OpenCodex WebSocket and does not disable this upstream OpenCodex-to-ChatGPT WebSocket path.

The runtime gate appears relevant:

• v2.28.0 package dependency: Bun 1.3.14
• v2.31.0 package dependency: Bun 1.4.0
• MIN_BOUNDED_CODEX_WS_BUN_VERSION = "1.4.0"
• shouldUseCodexWsUpstream(...) therefore becomes active after the upgrade.
• The upstream implementation sends the complete JSON request as one response.create WebSocket message.
• I did not find an outbound body-size gate before selecting WS.

A safe mitigation may be a pre-send size-based fallback to HTTP/SSE, or an explicit upstream transport setting. Retrying over HTTP only after an opened WS closes may risk duplicate generation, so a decision before opening WS seems safer.

Version

2.31.0

Operating system

macOS 26.5.2 (Build 25F84), Apple Silicon

Provider and model

OpenAI ChatGPT account / gpt-5.6-luna / Responses

Logs or error output

OpenCodex: 2.31.0
Bundled Bun: 1.4.0
Codex CLI embedded in App: 0.149.0-alpha.4.1

Codex App:
stream disconnected before completion:
Upstream stream terminated unexpectedly:
codex websocket closed before a Responses terminal event

OpenCodex:
status: 502
first output: none
close reason: upstream WebSocket closed before a Responses terminal event
repeated attempts: approximately 3.8-5.3 seconds each

Screenshots and supporting files

No payload or screenshots attached because the request contains private task history. The sizes, version comparison, and redacted error above are reproducible from local logs.

Relevant release/runtime evidence:

• v2.31.0 release: https://github.com/lidge-jun/opencodex/releases/tag/v2.31.0
• Bun bump commit: 27764f3

Redacted configuration

{
  "port": 10100,
  "defaultProvider": "openai",
  "websockets": false,
  "providers": {
    "openai": {
      "adapter": "openai-responses",
      "baseURL": "https://chatgpt.com/backend-api/codex"
    }
  }
}

Checks

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

[lidge-jun]

리뷰 · 우선순위 64 / 80

설명: 이 이슈는 코덱스 앱의 긴 일을 2.31.0 으로 올린 뒤, 예전에는 되던 큰 요청이 502 로 죽는다고 한다. 지금 CURRENT dev HEAD 는 4f41a8e93 이다. 이번 시간에 origin/dev 는 그대로다. 새 머지는 없다. 착지는 여전히 2396 사용량 CLI 오늘 비용이다. package.json 은 2.27.0 이다. src/config.ts 는 3975줄이다. src/runtime 폴더는 지금 HEAD 에 없다. 작성자는 메인 2.31.0 에서 재현했다. 지금 origin/dev 에도 같은 위 웹소켓 길이 있다.

작성자는 2.28.0 에서 같은 일, 같은 계정, 같은 약 18.2 메가 요청이 에이치티티피 에스에스로 200 이 났다고 했다. 압축 전 약 18200828 바이트, 압축 후 약 11513677 바이트다. 2.31.0 은 번들 번이 1.4.0 이다. 같은 크기 약 18197133 바이트가 위 웹소켓에서 반복해서 죽는다. 짧은 대화는 같은 계정과 모델로 산다. 설정 websockets 를 꺼도 안 고쳐진다. 그 칸은 데스크톱에서 오픈코덱스로 들어오는 웹소켓만 끈다.

지금 HEAD 의 src/server/responses/ws-upstream.ts 30줄 MIN_BOUNDED_CODEX_WS_BUN_VERSION 은 1.4.0 이다. 72줄 bunSupportsBoundedCodexWsRelay 는 1.3.14 에서 거짓이고 1.4.0 에서 참이다. 82줄 shouldUseCodexWsUpstream 은 번이 되고, 주소가 코덱스 응답 주소이고, 포스트이고, 본문이 글자이고, 맨 위 stream 이 참이면 위 웹소켓을 고른다. 본문 크기를 보는 칸은 없다. src/server/responses/fetch-helpers.ts 166줄이 그 함수가 참이면 위 웹소켓 길이로 보낸다. 설정 칸은 src/config.ts 2971줄 websocketsEnabled 와 3408줄 기본값 거짓이다. src/server/index.ts 889줄은 들어오는 업그레이드만 426 으로 막는다. 위로 나가는 길은 이 칸을 안 본다.

위 길은 요청 제이슨 전체를 한 장의 response.create 로 보낸다. 11줄 주석, 125줄 stringify, 204줄 send 가 그 일이다. 열리기 전에 거절되거나, 보내기가 예외로 죽거나, 10초 안에 101 이 안 오면 에스에스로 넘어간다. 그때는 위 턴이 아직 없다. 열린 뒤에 위가 끊기면 300줄이 작성자가 본 그 문장을 낸다. 그때는 에스에스로 다시 보내지 않는다. 이미 위 턴이 시작됐을 수 있어서다. 29줄 MAX_CODEX_WS_QUEUE_BYTES 는 받는 큐 8메가다. 보내는 쪽 한도는 없다. 18.2 메가는 그 받는 한도보다 크다. 고치는 PR 은 아직 없다. 작성자가 말한 대로, 열기 전에 크기를 보고 에스에스로 가는 편이 다시 보내서 두 번 만드는 것보다 안전하다. 사용자 길이로는 긴 일이 502 로 끝나는 구멍이라서 64. 카탈로그 팁은 Ox Alpha x-preview-f-free + deepseek-v4-flash-vision-exp. Cursor 정적 카탈로그는 opus-4-8-fast / opus-5-fast. 2334 CursorCredentialRouter 는 여전히 src/providers/cursor-pool.ts 모듈+테스트만 있고 어댑터에 연결되지 않았다. 2332 H2 는 discovery 전용. 2320 overflow + 2342 는 이미 dev. 2188 사이드카는 이미 dev. 2382 데스크톱 앱 재시작은 이미 dev. 2292 는 아직 연다.

src/server/responses/ws-upstream.ts 라인 82 - shouldUseCodexWsUpstream 은 본문 크기를 안 본다. 조건이 맞으면 무조건 위 웹소켓이다
src/server/responses/ws-upstream.ts 라인 30 - 번 1.4.0 부터 이 길이 켜진다. 2.28.0 의 1.3.14 는 꺼져 있었다
src/server/responses/ws-upstream.ts 라인 204 - 요청 전체를 한 장으로 보낸다. 보내는 쪽 한도는 없다
src/server/responses/ws-upstream.ts 라인 300 - 열린 뒤에 위가 끊기면 그 문장을 내고 에스에스로 안 돌아간다
src/server/responses/fetch-helpers.ts 라인 166 - 조건이 참이면 위 웹소켓 길이로 보낸다
src/server/index.ts 라인 889 - 설정 websockets 는 들어오는 업그레이드만 끈다. 위로 나가는 길은 안 본다
src/config.ts 라인 3408 - 그 설정 기본값은 거짓이다. 작성자 재현도 거짓이다

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

• 열기 전에 크기 한도를 두고 에스에스로 내릴지. 한도는 몇 바이트로 할지
• 위로 나가는 길을 끄는 설정 칸을 따로 둘지. 지금 websockets 칸은 들어오는 문만 본다
• 메인 2.31.0 핫픽스인지, origin/dev 에 먼저 넣을지. 지금 HEAD 에도 같은 구멍이 있다
• 2210 과 한 이슈로 묶지 말 것. 제공자와 증상이 다르다

너의 추천
이슈는 열어 둔다. 고치는 PR 이 오면 그 PR 로 닫는다. 열기 전에 크기를 보고 에스에스로 내리는 쪽이 맞다. 열린 뒤에 다시 보내서 두 번 만들지 말 것. 호출 길을 넓히지 말 것. 2210 과 2279 는 닫지 않는다. 라벨은 그대로 둔다. 프리뷰 배포가 아니다.

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