›_ Codex Issues
Codex Issues / #35094

Realtime V3: WebRTC call creation succeeds but sideband returns 404 call_id_not_found

Open 💬 2 comments Opened Jul 24, 2026 by AmirTlinov

What version of Codex is running?

  • Installed CLI: codex-cli 0.145.0
  • Codex Desktop bundled runtime: reproduced with both the stable runtime and 0.146.0-alpha.3
  • Platform: macOS arm64
  • Auth mode: ChatGPT login
  • Realtime request: version: v3, transport: WebRTC, model: gpt-live-1-codex

What issue are you seeing?

Codex Desktop successfully creates a fresh Realtime V3 WebRTC call, but the sideband WebSocket cannot join that same call.

Observed request sequence:

POST https://chatgpt.com/backend-api/codex/realtime/calls
-> 201 Created
-> Location contains a fresh rtc_* call_id

GET wss://api.openai.com/v1/live/<same-fresh-call-id>
-> 404 Not Found
-> call_id_not_found / No session found for the provided call_id

The 404 occurs immediately after call creation and repeats across sideband retries, so this is not an expired call id.

The source comment in sideband_websocket_auth_headers says that for ChatGPT-auth sessions, transceiver is expected to accept the same call-create identity on the direct api.openai.com sideband path. That handoff does not appear to happen for this account/session.

What steps reproduce the bug?

  1. Enable realtime_conversation.
  2. Sign in with ChatGPT auth.
  3. Open Codex Desktop and start Voice.
  4. Desktop sends thread/realtime/start with V3 + WebRTC.
  5. Wait for the call creation response and sideband join.
  6. Voice exits with:
Voice chat error: stream disconnected before completion:
failed to connect realtime websocket: HTTP error: 404 Not Found

Expected behavior

The V3 sideband WebSocket joins the fresh WebRTC call and Voice remains connected.

Diagnostic evidence / controls

  • Ordinary Codex Responses WebSocket connectivity succeeds with HTTP 101 Switching Protocols.
  • Reproduced through two different VPN exit regions (US and Sweden), with chatgpt.com, api.openai.com, and auth traffic using the same exit route in each test.
  • A synthetic app-server V3 call reproduced the same immediate call_id_not_found using the bundled 0.146.0-alpha.3 runtime.
  • Forcing the V3 sideband to the ChatGPT backend path changes the failure to 403 Forbidden, including from the real Desktop process where DeviceCheck attestation is generated.
  • Forcing call creation to https://api.openai.com/v1/live returns 500 Internal Server Error with a Location/rtc_* header, but that id also has no joinable session and returns call_id_not_found.
  • V1 WebRTC is denied with Voice session access denied.
  • V2 is rejected because AVAS WebRTC requires V1 or V3.
  • Standalone WebSocket transport is not a ChatGPT-auth workaround because it requires API-key auth.
  • Re-authentication is unlikely to explain the split: the authenticated ChatGPT backend creates the call successfully, and the exact matching auth/account headers are forwarded to the sideband as implemented in current source.

No access tokens, account ids, call ids, public IPs, or attestation values are included here. I can provide request ids / CF-Ray values privately if maintainers need them.

View original on GitHub ↗

2 Comments

shuncong · 1 month ago

I can reproduce the same call-creation/sideband handoff failure in the current Codex Desktop app, with the sideband variant returning HTTP 403.

Environment:

  • Codex Desktop: 26.721.41059 (bundle 5848)
  • Bundled runtime: codex-cli 0.146.0-alpha.3.1
  • Platform: macOS arm64
  • Auth: ChatGPT login, Plus plan
  • Realtime transport: WebRTC

Observed sequence from the real Desktop process:

thread/realtime/start -> success
realtime_session_started
realtime_session_updated -> fresh rtc_* call id
sideband WebSocket handshake -> HTTP 403 Forbidden

Desktop retried the complete sequence once. Both attempts created a different fresh rtc_* id and both failed at the sideband handshake with:

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

Additional controls:

  • DeviceCheck attestation was generated successfully before the failure.
  • Voice listing and thread/realtime/start both succeeded.
  • Normal Codex text conversations work.
  • chatgpt.com and ws.chatgpt.com were routed through the same proxy exit.
  • ws.chatgpt.com:443 is reachable; an unauthenticated HTTPS request reaches the edge and returns 404 rather than a network or TLS failure.
  • The configured provider is a local alias, but its base_url is the official https://chatgpt.com/backend-api/codex, with wire_api = "responses" and requires_openai_auth = true; no third-party endpoint participates in this voice attempt.

This strongly matches the cross-service Realtime call/session handoff or sideband authorization problem described here. I can provide sanitized timestamps or additional Desktop logs if useful.

aaajiao · 1 month ago

Related OAuth-only live signal from OpenClaw v2026.7.2-beta.5 with bundled codex-cli 0.145.0. I am not claiming this is proven to be the same failure stage as the reported sideband 404, because OpenClaw does not expose the underlying call-create/sideband wire trace in this path.

Environment:

  • macOS arm64 / Node 24
  • ChatGPT/Codex OAuth only; no OpenAI Platform API key available to the Gateway
  • Codex app-server thread/realtime/start, version: "v3", WebRTC
  • reproduced from both a macOS browser client and iOS

The browser offer was produced by a real RTCPeerConnection: microphone track added before createOffer(), oai-events data channel created, and offer.sdp posted successfully to OpenClaw's local Codex broker. The broker accepted the request, but Codex app-server never emitted either thread/realtime/sdp or an explicit realtime error. OpenClaw therefore failed after its 60-second wait with:

502 Codex realtime SDP answer timed out

Adding an actual audio track versus a synthetic offer did not change the result. A v2 WebRTC control was rejected immediately with AVAS realtime calls require realtime v1 or v3; v1 was not a usable ChatGPT-auth fallback.

This may be an earlier manifestation of the same v3 + ChatGPT-auth call/session handoff problem, but without the wire trace I cannot assert that call creation succeeded and then hit the exact call_id_not_found sideband step described here. The OpenClaw-side tracking issue and fuller reproduction are at https://github.com/openclaw/openclaw/issues/115021.