fix(responses): disable unsafe custom websocket upstreams

[luvs01]

Motivation

• An opt-in upstreamWebsocket path allowed arbitrary configured HTTPS Responses endpoints to enter Bun's WebSocket client path, but Bun's client API assembles complete messages (including fragmented text/binary frames) before JS handlers run, letting a malicious upstream force unbounded allocations and crash the process.
• The safe immediate mitigation is to keep non-canonical/custom providers on the bounded HTTP/SSE relay until the runtime can enforce an inbound message-size limit during ingestion; preserve the canonical ChatGPT fast WS path.

Description

• Restrict upstream WebSocket eligibility so only the canonical ChatGPT Responses URL is eligible and arbitrary provider URLs never take the native WebSocket lane by returning false from shouldUseCodexWsUpstream for non-canonical URLs and rejecting non-canonical dial attempts in wsUpstreamUrlFor (changes in src/server/responses/ws-upstream.ts).
• Gate the dialing path in codexWsUpstreamFetch to fall back to the HTTP/SSE helper when the request URL is not the canonical Responses URL or the runtime lacks the bounded relay capability (change in src/server/responses/ws-upstream.ts).
• Keep upstreamWebsocket as a compatibility config flag but mark it ignored for custom providers and update multi-locale docs to state this (changes in docs-site/src/content/docs/**/reference/configuration/providers.md).
• Update tests to assert that opted-in custom providers remain on bounded HTTP/SSE and to cover the fallback behavior (changes in tests/ws-upstream.test.ts).

Testing

• Ran the focused WebSocket suite with a bounded Bun runtime: npx --yes bun@1.4.0 test tests/ws-upstream.test.ts --timeout 15000, which passed the suite (39 passed, 1 skipped).
• Verified typecheck and other repository checks: npx --yes bun@1.4.0 x tsc --noEmit and npx --yes bun@1.4.0 run privacy:scan completed successfully, and the docs build for docs-site completed (cd docs-site && npx --yes bun@1.4.0 install --frozen-lockfile && npx --yes bun@1.4.0 run build).
• Attempted the full test suite (npx --yes bun@1.4.0 run test) but observed pre-existing unrelated timeouts / lab assertions outside the touched WebSocket surface; the focused WebSocket tests that validate the security fix pass with the required runtime.

---

Codex Task

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-03T06:07:17.899444Z	3efbf0e	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Team

Run ID: da7445dc-7810-413d-a565-a58f3a149e32

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[github-actions]

✅ READY

• all PR quality gates passed.

Hygiene

✅ Deterministic PR hygiene checks passed.