[Bug][Windows][Zhipu] Bun 1.4.0 causes GLM-5.3 streams to fail with 502; the same OpenCodex 2.33 setup works on Bun 1.3.14

[stud-f]

Client or integration

Codex App

Area

Provider adapter

Summary

On Windows, real streaming inference through the Zhipu BigModel Coding Plan provider fails when OpenCodex 2.33.0 runs on its bundled Bun 1.4.0 runtime.

Both zhipu-bigmodel-coding/glm-5.3 and zhipu-bigmodel-coding/glm-5.3-flash return HTTP 502 with:

Provider stream error:
The socket connection was closed unexpectedly.
For more information, pass `verbose: true`
in the second argument to fetch()

Provider discovery and authentication remain healthy. Changing only the proxy runtime from Bun 1.4.0 to Bun 1.3.14 makes both models complete with HTTP 200.

Expected: both Bun versions should successfully relay the same Zhipu SSE responses, or OpenCodex should provide a compatible fallback for the affected runtime path.

Reproduction

1. Install OpenCodex 2.33.0 on Windows. Its bundled runtime is Bun 1.4.0.
2. Configure the Zhipu BigModel Coding Plan provider as shown in the redacted configuration below.
3. Confirm that discovery succeeds:

ocx provider test zhipu-bigmodel-coding --json

Observed result:

ok=true
models=10
latencyMs≈170

4. Confirm with ocx doctor that the service proxy is running on Bun 1.4.0.
5. In a fresh Codex App conversation, send the same short text-only prompt to:
   • zhipu-bigmodel-coding/glm-5.3
   • zhipu-bigmodel-coding/glm-5.3-flash
6. Both requests fail with HTTP 502 / upstream_server_error / unexpected socket close.
7. Keep OpenCodex, Codex, provider configuration, credential, endpoint, models, prompt, network, and VPN unchanged.
8. Set the documented runtime override to Bun 1.3.14 and regenerate the Windows service:

$env:OPENCODEX_BUN_PATH = "C:\redacted\bun-1.3.14\bun.exe"
ocx service install

9. Confirm with ocx doctor that the service PID is now using Bun 1.3.14.
10. Repeat the two requests in fresh conversations. Both complete with HTTP 200.

Controlled result:

OpenCodex	Proxy runtime	GLM-5.3	GLM-5.3-Flash
2.33.0	Bun 1.4.0	502 / socket closed	502 / socket closed
2.33.0	Bun 1.3.14	HTTP 200	HTTP 200

Version

2.33.0

Operating system

Windows 11 Home 24H2, build 26100, x64

Provider and model

Zhipu BigModel Coding Plan (zhipu-bigmodel-coding):

• glm-5.3
• glm-5.3-flash

Logs or error output

stream disconnected before completion:
Provider stream error:
The socket connection was closed unexpectedly.
For more information, pass `verbose: true`
in the second argument to fetch()

The OpenCodex dashboard records:

HTTP 502
errorCode: upstream_server_error
upstreamError: Provider stream error: The socket connection was closed unexpectedly

No request IDs or credentials are included.

Screenshots and supporting files

The controlled A/B matrix is included above. Additional redacted logs can be supplied if a maintainer requests specific non-secret fields.

Redacted configuration

{
  "providers": {
    "zhipu-bigmodel-coding": {
      "adapter": "openai-chat",
      "baseUrl": "https://open.bigmodel.cn/api/coding/paas/v4",
      "authMode": "key"
    }
  }
}

The same configuration was used in both runtime tests.

Additional context

• Model discovery succeeds under both runtimes; only real streaming inference fails.
• The same Zhipu API credential and endpoint are used in both tests.
• OpenCodex 2.20.0 with Bun 1.3.14 had also previously completed GLM-5.3 requests successfully.
• This is strong single-variable evidence for a Windows + Bun 1.4.0 + Zhipu streaming incompatibility. It does not yet identify whether the final defect is in Bun fetch/SSE handling, socket lifecycle, the OpenAI Chat adapter, or an interaction between them.
• Related but not duplicate: runtime: Bun 1.4 preview-dev product candidate stack #1691, [Bug] Streaming requests to opencode.ai hang with HTTP/2 SSE (200s timeout → 502/499, Codex stuck on 'thinking') #1668, [Bug]: npm launcher ignores OPENCODEX_BUN_PATH for direct starts and update fallbacks #721, and [Provider compatibility] Complete Z.AI GLM-5.3 Coding Plan metadata #1734.

Checks

• I searched existing open and closed issues, pull requests, and documentation.
• I removed API keys, tokens, account identifiers, request IDs, emails, and personal paths.

[lidge-jun]

리뷰 · 우선순위 66 / 80

Windows에서 Zhipu BigModel Coding Plan(zhipu-bigmodel-coding, 어댑터 openai-chat)으로 glm-5.3/glm-5.3-flash 스트림을 보내면, OpenCodex 2.33.0에 묶인 Bun 1.4.0에서는 소켓이 갑자기 닫히며 502/upstream_server_error가 난다. 발견(ocx provider test ok, 모델 10개)과 인증은 살아 있다. 같은 OpenCodex·같은 설정·같은 키로 OPENCODEX_BUN_PATH만 Bun 1.3.14로 바꾸면 둘 다 200이다. 단일 변수 A/B라서 “Windows + Bun 1.4.0 + 이 Zhipu SSE 경로” 쪽 가능성이 크다. 최종 결함이 Bun fetch/SSE인지, openai-chat 어댑터인지, 둘의 만남인지는 아직 이 이슈만으로 단정할 수 없다.

지금 dev도 번들 Bun은 1.4.0이다. package.json의 bun/@types/bun이 1.4.0이고, src/lib/bun-stream-caps.ts는 Bun#32111(eager SSE 쪽 use-after-free) 수정이 들어간 첫 릴리스로 1.4.0을 MIN_FIXED_BUN_VERSION에 적어 두었다. 즉 제품은 메모리/릴레이 안전을 위해 1.4.0을 기본으로 올린 상태다. 제보의 임시 처방(1.3.14 오버라이드)은 src/lib/bun-runtime.ts의 OPENCODEX_BUN_PATH로 이미 지원되지만, 그 런타임은 32111 계열에서는 “known-bad” 쪽으로 분류된다. doctor도 Windows에서 영향받는 Bun을 경고한다. 장기 답은 1.3.14로 내리는 것이 아니라, 1.4.0에서도 Zhipu 스트림이 닫히지 않게 만드는 것이다.

관련으로 보이는 #1691/#1668/#721/#1734는 스트림/플랫폼 이웃이지만, 이 티켓의 통제된 Bun 버전 A/B와 같은 증거가 아니다. 중복으로 닫지 마라. types/config 분할과도 무관하다. Kiro 쿼터·카탈로그 작업과 겹치지 않는 독립 플랫폼 버그다.

src/lib/bun-stream-caps.ts MIN_FIXED_BUN_VERSION - 번들 기본이 1.4.0인 이유(Bun PR #32120 / #32111)가 여기 적혀 있다. Zhipu 502 때문에 전역으로 1.3.14로 내리면 다른 OS/경로의 메모리 이슈가 다시 열린다.

src/lib/bun-runtime.ts OPENCODEX_BUN_PATH - 제보자가 쓴 오버라이드 통로다. 임시 완화는 여기로 안내하면 된다. 기본 번들을 바꾸라는 신호가 아니다.

경로/openai-chat + Zhipu baseUrl - 설정은 https://open.bigmodel.cn/api/coding/paas/v4의 coding paas다. 발견은 되고 스트림만 죽는다. 헤더/청크/Keep-Alive/프록시 버퍼 차이를 1.3.14 vs 1.4.0에서 같은 요청으로 찍는 재현이 필요하다.

경로/Windows service - ocx service install이 고른 Bun이 doctor에 그대로 보인다. 서비스 PID의 Bun 버전을 제보에 이미 적어 두었으니, 재현 절차는 충분하다.

경로/#1691 #1668 #721 #1734 - 이웃 이슈로만 링크하고, 이 Bun A/B 증거 없이는 합치지 마라.

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

• 최소 재현을 Windows CI/스모크에 넣을지, 수동 매트릭스만 남길지
• 완화책을 문서의 OPENCODEX_BUN_PATH로만 둘지, Zhipu(또는 특정 SSE)만 legacy-tee/다른 fetch 경로로 우회할지
• Bun 업스트림 이슈로 올릴지, ocx 쪽 워크어라운드를 먼저 넣을지
• 2.33/2.35/2.36(dev 번들 1.4.0) 어디에 핫픽스 노트를 붙일지

너의 추천
이 이슈는 열어 둔다. 당장 사용자에게는 OPENCODEX_BUN_PATH로 1.3.14를 쓰는 임시 완화를 안내하되, 기본 번들을 내리지는 마라. 다음 패치는 같은 요청을 1.3.14/1.4.0에서 바이트 단위로 비교해 소켓이 닫히는 지점(헤더 수신 전후, 첫 SSE 이벤트, 툴 델타 등)을 잠그는 것이다. 원인 후보가 Bun이면 업스트림 이슈 + ocx 쪽 좁은 우회, ocx 어댑터면 openai-chat/Zhipu 경로만 고친다. types/config 분할 때문에 닫을 대상이 아니다.

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

[lidge-jun]

Partially addressed on dev in 22f2df6 (#2908) — deliberately not closing this, because
what got fixed is not the cause you reported.

What was fixed. The routed request path honors a provider's upstreamHttpVersion pin, but
the web-search path bypassed it entirely: the loop called bare global fetch whenever the
adapter has no fetchResponse, which is always true for openai-chat providers like Zhipu. So
anyone setting upstreamHttpVersion: "http1.1" to work around an HTTP/2 transport failure had
that setting silently ignored on every web-search turn. The hosted-search sidecar ignored its
own provider's pin the same way. Both legs now route through the shared provider-fetch
wrapper, with each leg keeping its own credentials.

What was not fixed. This does not explain why Bun 1.4.0 fails where 1.3.14 succeeds. Your
configuration does not set upstreamHttpVersion at all, so the propagation gap cannot be the
cause of the 502 you saw — it only meant the documented workaround could not help you on
web-search turns. Whether the root cause is Bun, Zhipu's SSE behavior, or their interaction is
still open, which is why this issue stays open.

If you are able to retest once this reaches a release: setting upstreamHttpVersion: "http1.1"
on the Zhipu provider should now actually take effect end to end. If GLM-5.3 streams work with
that pin and fail without it, that isolates the failure to HTTP/2 negotiation and is the single
most useful data point for the remaining half.