Realtime V3 (macOS, 0.146.0-alpha.3.1): default sideband dials wss://chatgpt.com/backend-api/codex/<call_id> and is blocked by Cloudflare (cf-mitigated: challenge) → 403

Related to #35094, but a different sideband address and a different failure mechanism, so filing separately and cross-linking. #35094 reports the default V3 sideband as wss://api.openai.com/v1/live/<call_id> returning 404 call_id_not_found; on this build the client dials the ChatGPT backend by default and gets 403. #35094 mentions the 403 variant only as something reached by forcing the sideband path — here it is the default, unforced behaviour.

Also distinct from #18456: that one is a User-Agent–dependent Cloudflare block on reqwest clients. This one is User-Agent–independent (control table below).

What version of the Codex App are you using (From "About Codex" dialog)?

App 26.721.41059, bundled runtime codex-cli 0.146.0-alpha.3.1 (ChatGPT.app/Contents/Resources/codex). Homebrew codex-cli 0.145.0 is also installed but is not the binary driving Voice.

What subscription do you have?

Paid ChatGPT subscription (Plus).

What platform is your computer?

macOS 25.5.0, arm64 (Apple Silicon). Cloudflare edge POP SIN.

What issue are you seeing?

Voice chat fails with:

Voice chat error: stream disconnected before completion:
failed to connect realtime websocket: HTTP error: 403 Forbidden

The WebRTC leg succeeds and the sideband WebSocket leg is refused, so audio comes up for roughly a second and then Voice tears itself down when the sideband retry loop is exhausted ~6s later.

Observed sequence, with no experimental_realtime_* overrides set and nothing forced:

POST https://chatgpt.com/backend-api/codex/realtime/calls?intent=quicksilver&architecture=avas
-> 201 Created
-> Location: /v1/realtime/calls/rtc_u0_<redacted>
-> x-codex-plan-type: plus
-> x-codex-active-limit: premium
-> x-codex-primary-used-percent: 2

INFO  codex_api::endpoint::realtime_websocket::methods
      connecting realtime websocket: wss://chatgpt.com/backend-api/codex/rtc_u0_<redacted>
WARN  realtime sideband websocket connect failed; retrying:
      stream error: failed to connect realtime websocket: HTTP error: 403 Forbidden
      attempt=1 delay_ms=218
      attempt=2 delay_ms=387
      attempt=3 delay_ms=741
      attempt=4 delay_ms=1528
WARN  codex_core::realtime_conversation
      failed to connect realtime sideband: stream disconnected before completion:
      failed to connect realtime websocket: HTTP error: 403 Forbidden
INFO  received realtime conversation event event=Error(...)
TRACE app-server event: thread/realtime/error
TRACE app-server event: thread/realtime/closed

Two things to note in that trace:

1. The call-create response returns Location: /v1/realtime/calls/rtc_u0_..., but the sideband URL the client then dials is <base_url>/<call_id> — the /v1/realtime/calls/ prefix is dropped.
2. The 403 is not an OpenAI application response. It is a Cloudflare bot-management challenge; the request never reaches the application (evidence below).

What steps can reproduce the bug?

1. Sign in with ChatGPT auth (Plus) on macOS arm64.
2. Codex Desktop 26.721.41059 with bundled runtime 0.146.0-alpha.3.1, realtime_conversation enabled.
3. Start Voice.
4. Call creation returns 201; the sideband WebSocket connect to wss://chatgpt.com/backend-api/codex/<call_id> returns 403 and retries 5 times.
5. Voice closes with the error above.

What is the expected behavior?

The sideband WebSocket joins the freshly created WebRTC call and Voice stays connected.

Additional information

The 403 is a Cloudflare challenge, not an application response

Same access token, same chatgpt-account-id, same machine, same TLS client, run within minutes of a live failure:

| path under https://chatgpt.com/backend-api/codex/ | method | result |
|---|---|---|
| models?client_version=0.145.0 | GET | 200 application/json |
| realtime/calls | POST {} | 400 application/json — reaches the app |
| realtime/calls | GET | 405 application/json — reaches the app |
| rtc_u0_<test> — what the client dials | GET and WS-upgrade | 403 text/html, cf-mitigated: challenge |
| realtime/calls/rtc_u0_<test> | WS-upgrade | 403 cf-mitigated: challenge |
| v1/realtime/calls/rtc_u0_<test> | WS-upgrade | 403 cf-mitigated: challenge |
| realtime/rtc_u0_<test> | WS-upgrade | 403 cf-mitigated: challenge |
| realtime/calls/rtc_u0_<test>/sideband | WS-upgrade | 403 cf-mitigated: challenge |

Every 403 carries server: cloudflare, cf-mitigated: challenge, content-type: text/html, accept-ch: Sec-CH-UA-*, and a ~10KB interstitial HTML body.

Control 1 — not upgrade-dependent. A plain GET with no Upgrade / Connection / Sec-WebSocket-* headers is challenged identically. The mitigation keys on the path, not on the WebSocket handshake.

Control 2 — not User-Agent-dependent, which distinguishes this from #18456:

| User-Agent | models | rtc_u0_<test> |
|---|---|---|
| codex_cli_rs/0.146.0 | 200 | 403 cf-mitigated: challenge |
| Chrome 150 macOS browser UA | 200 | 403 cf-mitigated: challenge |
| (no User-Agent header) | 200 | 403 cf-mitigated: challenge |

So requests carrying the call id never reach the application. They are challenged at the edge, consistent with that path not being covered by the API route exemptions that models and realtime/calls are covered by.

Client-side network ruled out

• No proxy — scutil --proxy has no HTTPProxy / HTTPSProxy keys, and no *_proxy environment variables are set
• No MITM tooling running (no Proxyman / Charles / mitmproxy)
• No VPN exit node in use; default route is the physical LAN interface and egress is the real ISP address
• codex_ca_certificate_configured=false ssl_cert_file_configured=false, "using system root certificates" — no certificate interception
• A network-level block would also break models and realtime/calls; both succeed

Not entitlement or quota

The call-create response is 201 with x-codex-plan-type: plus, x-codex-active-limit: premium, x-codex-primary-used-percent: 2. A genuine cap on this account on a different day produced a clearly distinct error (failed to start realtime conversation: You've hit your usage limit. Upgrade to Pro), so the two are easy to tell apart in logs.

No client-side override recovers it

experimental_realtime_ws_base_url and experimental_realtime_webrtc_call_base_url exist in the 0.146 binary, but all five candidate ChatGPT-backend path shapes in the table above are challenged, so there is no config.toml value that restores Voice on this build.

Possible relevance to #35094

If the ChatGPT-backend sideband path is edge-challenged rather than served, then api.openai.com/v1/live/<call_id> is the only sideband address that can currently reach a transceiver — and #35094 reports that one returning call_id_not_found. Both sideband addresses would then be unreachable for ChatGPT-auth sessions by two different mechanisms, which would explain why neither forcing direction produces a working call.

Log history for this account

realtime_websocket::methods connect attempts appear only from the failing session onward. Earlier Voice sessions on the same machine and account started successfully without any sideband connect being attempted, which suggests the sideband leg became active for this session/build rather than having always been on this path.

No access tokens, account ids, user ids, installation ids, real call ids, public IP addresses, or cookies are included above. Call ids in log excerpts are redacted and all probe ids are synthetic.