Control UI Chat Talk shows stale gpt-realtime error even when gateway-relay talk.session.create succeeds

Summary

In the Chat window on Control UI v2026.5.27, toggling Talk can show:

The model 'gpt-realtime' does not exist or you do not have access to it

But local gateway logs show the gateway-relay Talk path is configured correctly and talk.session.create succeeds. The visible error appears to be stale or mismatched with the current failing path.

Environment

• OpenClaw Control UI: v2026.5.27
• Surface: Chat window / webchat
• Host: macOS (Apple Silicon)
• Gateway mode: local
• Talk provider: openai
• Talk realtime transport: gateway-relay
• Talk model: gpt-realtime
• Talk brain: agent-consult

Expected behavior

• Chat Talk should use the configured gateway-relay path.
• The UI should clear old Talk errors on a fresh start.
• The UI should only surface the current failure, not stale text from a previous path.

Actual behavior

• The Chat window shows The model 'gpt-realtime' does not exist or you do not have access to it.
• However, logs show talk.session.create succeeding on the relay path.
• After startup, the session may close immediately and the browser can emit a follow-on talk.session.appendAudio error with Unknown Talk session.
• The visible Chat error remains the old gpt-realtime message rather than reflecting the current path/state.

Reproduction notes

1. Open the Chat window in Control UI.
2. Start Talk.
3. Stop Talk / retry Talk.
4. Observe the stale gpt-realtime access error in Chat.
5. Compare with local gateway logs.

Relevant observations

Before local hotfix

The Control UI bundle appeared to try talk.client.create first even for relay/auto sessions, then fall back to talk.session.create.

Observed repeatedly on Friday, May 29, 2026:

• 8:04:53 PM EDT: talk.client.create rejected, then talk.session.create succeeded
• 8:07:02 PM EDT: same pattern
• 8:11:28 PM EDT: same pattern
• 8:12:41 PM EDT: same pattern

Representative log pattern:

• talk.client.create -> INVALID_REQUEST -> talk.client.create is client-owned; use talk.session.create for gateway-relay
• followed by successful talk.session.create

After local hotfix to prefer relay first

I patched the local Control UI bundle so relay/auto Talk prefers talk.session.create before talk.client.create.

After that patch, logs showed direct relay startup instead of the old wrong-path call:

• Friday, May 29, 2026, 8:21:11 PM EDT: talk.session.create succeeded directly
• immediately followed by Talk events:
  • turn.started
  • session.closed
• then:
  • talk.session.appendAudio -> UNAVAILABLE -> Error: Unknown Talk session

So after removing the original bad startup path, the Chat UI still showed the same old gpt-realtime error text.

Why this looks like a UI/client bug

This looks like some combination of:

1. stale Talk error state not being cleared on a fresh Talk start
2. a shutdown race where browser audio append continues briefly after relay session close
3. Chat surfacing an old or unrelated error string instead of the current failure

Local workaround tested

I locally patched the Control UI bundle to:

1. prefer talk.session.create first when transport is blank or gateway-relay
2. clear stale Talk error state on a new Talk start
3. ignore the benign Unknown Talk session append-audio race during shutdown

Even after that, the user still reported seeing the same gpt-realtime error text in Chat.

Config sanity check

The local config remained set to the expected relay path:

• provider: openai
• model: gpt-realtime
• transport: gateway-relay
• brain: agent-consult

So this does not look like a simple misconfigured Talk model/transport.

Suggested areas to inspect

• Control UI Chat Talk error state lifecycle / clearing logic
• relay session start/stop state transitions in Chat UI
• append-audio shutdown race after session.closed
• any path where old browser/WebRTC errors can persist into current relay-mode UI state

Notes

I can provide exact local bundle patch details if helpful, but I’m filing this mainly because the visible Chat error appears misleading relative to the real runtime path and makes Talk diagnosis much harder.