›_ Codex Issues
Codex Issues / #40140

thread/realtime/start (WebRTC, ChatGPT auth) fails since 2026-08-22 ~15:30Z: "Field `session.model` is not allowed for this Codex realtime session"

Resolved 💬 3 comments Opened Aug 22, 2026 by souchida Closed Aug 24, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What happened

Starting a realtime conversation through codex app-server --enable realtime_conversation
(thread/realtime/start, version: "v3", outputModality: "audio", transport: {type: "webrtc", sdp})
has failed on every attempt since 2026-08-22 ~15:30Z. Last successful start on this machine: 2026-08-21T21:02Z.

ERROR codex_core::realtime_conversation: failed to start realtime conversation:
{"detail":"Field `session.model` is not allowed for this Codex realtime session"}
-> notification thread/realtime/error {"threadId": "...", "message": "{\"detail\":\"Field `session.model` is not allowed for this Codex realtime session\"}"}

Reproduction (no custom client needed)

  1. codex app-server --enable realtime_conversation (ChatGPT login, macOS arm64)
  2. initialize with capabilities: {experimentalApi: true}, thread/start
  3. thread/realtime/start with transport: {type: "webrtc", sdp: <any offer>} → error above.

Passing model: "gpt-realtime" or model: "gpt-realtime-1.5" explicitly gives the same error, so the backend rejects the
field, not a value. A syntactically dummy SDP also reaches the same error, i.e. the session config is rejected before SDP negotiation.

Analysis

codex-rs/core/src/realtime_conversation.rs (rust-v0.149.0, ~L1328) always sets model = Some(params.model ∨ experimental_realtime_ws_model ∨ DEFAULT_*),
so there is no configuration that omits session.model. main / 0.150.0-alpha.6 carry the same code.
Nothing changed client-side between the last success and the first failure (same binary, same config), so this looks like a backend-side validation change.

Versions

  • codex-cli 0.149.0 (also reproduced on the version installed before, and on 0.149.0 after upgrading)
  • macOS (Darwin 25.5), arm64, ChatGPT auth (websocket transport is not an option here: "realtime conversation requires API key auth")

Expected

Either the backend accepts session.model again, or the client omits it for Codex (ChatGPT-auth) realtime sessions.

View original on GitHub ↗

3 Comments

steegi · 5 days ago

Independently reproduced on a physical Samsung Galaxy Z Fold6 using ChatGPT authentication, native Android WebRTC, Codex Realtime v3, and current Codex source 8e649e3.
We verified from wire traces that the outgoing session object did not contain session.model, yet the service returned Field session.model is not allowed. Sending session: {} produced the same error; omitting session returned Field session must be an object.
This flow worked previously and now blocks all realtime voice sessions. No separate API key or custom backend is involved.

Miguelosaurus · 4 days ago

Independent sanitized reproduction from another native Codex Voice integration:

  • App Server: 0.149.0-alpha.4
  • Host: macOS arm64
  • Auth: ChatGPT-managed Codex auth; no API key
  • Flow: initialize with experimental API, create a fresh persisted realtime-enabled thread, then submit thread/realtime/start with the allowlisted v3 WebRTC transport shape
  • Request inspection: the integration sends no model field, no session field, and no nested model field
  • Result: thread/realtime/error reports Field session.model is not allowed for this Codex realtime session
  • Boundary: failure occurs before SDP negotiation / WebRTC establishment; no realtime-start acknowledgement and no PCM audio are observed
  • Regression baseline: the same native architecture and thread-scoped flow worked on App Server 0.147.0-alpha.6.6

This looks consistent with a server-side validation/protocol regression rather than a client-supplied model value. All identifiers, prompts, thread IDs, and local paths are omitted.

etraut-openai contributor · 4 days ago

Thanks for the detailed report. We’ve identified the cause: app-server’s default v3 model is no longer accepted for this ChatGPT-authenticated realtime flow.

As a workaround, explicitly set "model": "gpt-live-1-codex" in the parameters of your thread/realtime/start request, alongside "version": "v3". Keep your other parameters unchanged; don’t put model inside a nested session object.

The error message is misleading: it rejects the model selection, not the presence of the field. Omitting model causes app-server to supply its default.

We’re preparing a change to update that default. It isn’t released yet, but explicit model selection provides a workaround for existing versions.