openclaw - 💡(How to fix) Fix [Bug]: Control UI Talk OpenAI WebRTC 403 model_not_found for gpt-realtime

Summary

On OpenClaw 2026.5.18, Control UI Talk with the OpenAI realtime provider fails in Chrome with:

Realtime WebRTC setup failed (403)

I captured the failing browser request directly from the live OpenClaw Control tab via Chrome DevTools Protocol. The failing request is:

• POST https://api.openai.com/v1/realtime/calls
• Content-Type: application/sdp
• Authorization is a browser ephemeral client secret (Bearer ek_...)

The response body is:

{
  "error": {
    "message": "The model `gpt-realtime` does not exist or you do not have access to it.",
    "type": "invalid_request_error",
    "code": "model_not_found",
    "param": ""
  }
}

Environment

• OpenClaw CLI: 2026.5.18
• Gateway version: 2026.5.18
• macOS
• Google Chrome 148
• Talk config:
  • provider: openai
  • realtime transport: webrtc
  • model: gpt-realtime
  • voice: cedar

Reproduction

1. Configure Talk realtime for OpenAI with browser WebRTC transport and model gpt-realtime.
2. Open Control UI.
3. Open a session chat.
4. Click Start Talk.
5. Observe the UI error: Realtime WebRTC setup failed (403).

What I verified

Gateway-side client creation succeeds

The gateway is not failing at Talk session creation. Local gateway logs show successful talk.client.create responses around the failing attempts, for example:

• 2026-05-18T20:19:06.598-04:00 ⇄ res ✓ talk.client.create 355ms
• 2026-05-18T20:19:08.641-04:00 ⇄ res ✓ talk.client.create 253ms

Direct API access to gpt-realtime does work

Using the same OPENAI_API_KEY configured in OpenClaw:

• GET /v1/models/gpt-realtime returns the model object successfully.
• POST /v1/realtime/calls with that API key reaches OpenAI and returns a normal 400 invalid_offer for fake SDP, not 403 model_not_found.

Example direct POST /v1/realtime/calls response with intentionally fake SDP:

{
  "error": {
    "message": "Offer did not have an audio media section.",
    "type": "invalid_request_error",
    "code": "invalid_offer",
    "param": ""
  }
}

That makes this look less like simple lack of OpenAI realtime entitlement and more like a mismatch in the browser-ephemeral session/client secret path used by Control UI Talk.

Why this looks like an OpenClaw bug

OpenClaw Control UI is successfully creating the Talk client gateway-side, but the browser-side OpenAI call made with the minted ephemeral client secret is rejected as though gpt-realtime is unavailable. Meanwhile, the same underlying API key can:

• resolve gpt-realtime as a valid model, and
• hit /v1/realtime/calls directly without getting model_not_found.

So the current failure seems to be somewhere in the OpenClaw browser realtime handoff/session creation path rather than a generic browser WebRTC failure.

Requested help

Please check whether the browser-minted OpenAI realtime session/client secret path for Control UI Talk is:

• binding the wrong project/account context,
• minting a client secret with stale or mismatched model permissions,
• using an outdated OpenAI realtime session shape for browser WebRTC, or
• otherwise constructing a browser session that does not match the direct API path.

If helpful, I can also provide the exact local config block and more gateway log excerpts.