#893 is not fixed on macOS: #1025 repairs snapshots but the transport gate from closed #928 is still missing — Codex hangs on third-party Responses gateways #1127

Client or integration

Codex App

Area

Streaming

Summary

v2.10.2 still reproduces the hang reported in #893 on macOS. #894/#928 (our fix) were closed in favor of the maintainer-rewritten #1025, but #1025 only took the snapshot repair half. The transport gate half of #928 was never taken — and without it, enabling any client-facing repair (responsesItemIdRepair / responsesSnapshotRepair) silently kicks Darwin streamMode: "eager-relay" traffic back onto the tee()+JS-pull chain, which loses the client stream on macOS. Result: upstream returns 200, the Codex client never receives a single SSE event, and every turn hangs until the user cancels (visible as HTTP 499 in usage logs).

Root cause: selectEagerPath in src/lib/bun-stream-caps.ts still has the pre-#928 guard — if (needsClientRewrite || (platform !== "win32" && platform !== "darwin")) return null; — so any client rewrite forces tee on every platform. The #1025 block rewrite is correctly wired into the eager relay via rewriteBlocks, but the affected traffic never reaches the eager relay in the first place. The fix is the #928 transport gate: win32 rewrites stay on tee (the extra JS pull wrapper is part of the Bun#32111 crash shape); Darwin explicit eager composes the payload rewrites inline after the single reader, plus passing the composed rewritePayload/rewriteBudget into the eager relay at the src/server/responses/core.ts call site (today both are win32-only). We are running exactly this on top of v2.10.2 in production now. Happy to resubmit the gate as a fresh PR against current main if preferred; please also consider reopening #893.

Reproduction

1. macOS, streamMode: "eager-relay", a Responses-compatible relay provider (adapter openai-responses) with responsesSnapshotRepair: true and responsesItemIdRepair enabled.
2. POST /v1/responses with stream: true (any prompt) through the proxy, or simply chat from the Codex App.
3. Stock v2.10.2: client receives 0 SSE events and 0 [DONE] within 35 s while the upstream call logs 200. Codex hangs on every turn.
4. Same build + the fix(streaming): repair sparse Responses snapshots #928 transport gate: response.created → response.output_text.delta → response.completed → [DONE] — the turn commits normally. A/B run on isolated ports with identical config, same provider, real streamed requests.

Version

opencodex v2.10.2 (tag 2468502); Bun 1.3.14; Codex CLI 0.146.0 / Codex App

Operating system

macOS (darwin arm64), Darwin 25.5.0

Provider and model

Third-party Responses relay (adapter openai-responses), model gpt-5.6-sol

Logs or error output

# stock v2.10.2, isolated port, real streamed request (A):
#   35 s: zero SSE events observed client-side, zero "data: [DONE]"
# v2.10.2 + #928 transport gate (B), same config:
   1 response.completed
   2 response.created
   2 response.output_text.delta
   1 data: [DONE]
# live proxy usage during the regression window (client cancel visible):
20:15:12 {"model":"gpt-5.6-sol","provider":"<relay>","status":499,"durationMs":3855}
20:15:25 {"model":"gpt-5.6-sol","provider":"<relay>","status":200,"durationMs":8222}

Screenshots and supporting files

No response

Redacted configuration

{
  "streamMode": "eager-relay",
  "providers": {
    "<relay>": {
      "adapter": "openai-responses",
      "baseUrl": "<redacted>",
      "authMode": "key",
      "responsesSnapshotRepair": true,
      "responsesItemIdRepair": { "repairMissingTerminalIds": true }
    }
  }
}

Checks

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