Fix DeepSeek Responses over Codex WebSocket

[atian8179]

Summary

• keep the Codex client-facing Responses WebSocket enabled
• use a bounded JSON upstream response for official DeepSeek V4 Flash WebSocket turns
• preserve streaming behavior for ordinary HTTP/SSE Responses requests

Root cause

Codex Desktop initiates Responses turns over WebSocket. DeepSeek V4 Flash can deliver output for a streaming Responses request without delivering or closing on the terminal event, which leaves the Codex turn stuck indefinitely. Disabling the OpenCodex WebSocket transport is not a safe workaround: the built-in Codex provider probes WebSocket first, and its HTTP fallback can surface an opaque 503 Unknown error.

Fix

This adds a registry-only, per-model compatibility hint that is evaluated after final route selection. For an inbound WebSocket turn routed to the official DeepSeek V4 Flash transport, OpenCodex asks the upstream Responses endpoint for stream: false. The existing WebSocket bridge then reframes the bounded JSON response into the normal Responses WebSocket event sequence.

The hint is scoped to the registry-matched official transport, so custom providers with the same model name do not inherit it. HTTP/SSE requests continue to use upstream streaming.

Impact

DeepSeek V4 Flash can complete normally in Codex Desktop without weakening the WebSocket path required by native GPT models. Other providers and non-WebSocket requests are unchanged.

Validation

• bun test tests/deepseek-inbound-wire.test.ts — 16 passed, 0 failed
• bun run typecheck — passed
• git diff --check — passed for all changed files
• privacy patterns — passed for all changed files
• local Codex Desktop validation — native GPT and DeepSeek V4 Flash both completed; DeepSeek changed from hanging after first output to a completed turn

The full repository test run completed with 6,857 passes, 8 skips, 26 failures, and 5 dependency errors. The failures were outside the changed paths and were dominated by fixed-timeout tests under local filesystem load plus missing GUI React dependencies in the root install. The repository-wide privacy scanner was also blocked by the same macOS per-file read stalls, so the identical privacy patterns were applied directly to the five changed files instead.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 92aa3150-d2dc-4dbd-b120-e179efdb486d

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[lidge-jun]

Landed in #892 as 5dd965a (authorship preserved). Adversarial review caught one real gap on top of your patch: the bounded-JSON path read the upstream body with an unbounded .text(), so we folded in the house bounded-body primitive (32 MiB ceiling + 180s/30s transfer deadlines, fail-closed 502, partial bodies never parsed) in 9794e24/d8b707eaf. The registry-scoped hint design itself passed unchanged. Closing as superseded; thanks for the clean root-cause.