Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On iOS, Talk appears to start listening, but no voice interaction happens. The paired iOS node is connected, has microphone and speech-recognition permissions, advertises Talk/voice surfaces, and accepts ordinary node commands, so this does not look like a pairing, Tailscale, or generic command-channel failure.

Repeated Talk attempts create a Gateway realtime relay session, then the Gateway closes the session almost immediately. Subsequent audio appends on the same connection fail with Error: Unknown Talk session.

There is a second related routing issue: even after server config is changed to request talk.realtime.mode=stt-tts and talk.realtime.transport=managed-room, the iOS Talk path still starts as talkMode=realtime, talkTransport=gateway-relay, talkProvider=openai. The mobile client appears to override or ignore the server Talk routing config.

Steps to reproduce

1. Pair an iOS app node with a Gateway that has Talk configured.
2. Confirm the iOS node is awake and connected.
3. Confirm a basic node command works, for example device.status.
4. Open the iOS Talk/voice UI and start talking.
5. Watch Gateway logs for Talk session lifecycle events.
6. Optionally set server Talk realtime config to mode=stt-tts, transport=managed-room, brain=agent-consult, restart the Gateway, and repeat.

Expected behavior

The iOS Talk path should either:

• keep the created realtime session alive long enough to accept audio and complete the Talk turn, or
• honor the configured server Talk routing and use the configured STT/TTS route instead of forcing the realtime OpenAI gateway-relay path.

Actual behavior

The iOS Talk UI says it is listening, but nothing useful happens. Gateway logs show:

• talk.config succeeds
• Talk starts a realtime gateway relay session with provider openai
• session.closed is emitted almost immediately
• talk.session.appendAudio then fails with errorCode=UNAVAILABLE and errorMessage=Error: Unknown Talk session

A fresh repro showed turn.started with talkMode="realtime", talkTransport="gateway-relay", talkBrain="agent-consult", talkProvider="openai"; about 80ms later session.closed appeared, followed by two talk.session.appendAudio failures for Unknown Talk session.

OpenClaw version

Gateway: 2026.6.1 stable. npm latest stable also reported 2026.6.1.

Operating system

Gateway on macOS. iOS node reports platform iOS 26.6.0.

Install method

npm for Gateway. iOS app installed on iPhone.

Model

OpenAI realtime provider configured for Talk.

Provider / routing chain

Gateway Talk catalog reports realtime OpenAI configured and Microsoft STT/TTS configured.

Additional provider/model setup details

The iOS node reports version 2026.6.2. Node permissions include microphone=true and speechRecognition=true; capabilities include talk and voiceWake; commands include talk.ptt.start, talk.ptt.stop, talk.ptt.once, and talk.ptt.cancel.

A basic device.status node invoke succeeds while the app is awake, returning device status data. Tailscale connectivity was active/direct, and the Gateway was reachable through Tailscale Serve.

A separate APNS/background wake issue is visible in wake logs (path=no-registration / reason=no-registration), but the foreground Talk failure reproduces while the node is connected and awake.

openclaw update --tag beta --dry-run --json currently targets 2026.6.5-beta.1; no beta update was applied for this report.

Logs, screenshots, and evidence

talk.config succeeds
talk event turn.started talkMode="realtime" talkTransport="gateway-relay" talkBrain="agent-consult" talkProvider="openai"
~80ms later: talk event session.closed
talk.session.appendAudio -> errorCode=UNAVAILABLE errorMessage=Error: Unknown Talk session
talk.session.appendAudio -> errorCode=UNAVAILABLE errorMessage=Error: Unknown Talk session

After setting server config to request talk.realtime.mode=stt-tts, talk.realtime.transport=managed-room, and talk.realtime.brain=agent-consult, both openclaw config get talk --json and talk.config reflected those keys, but the iOS Talk attempt still used realtime/gateway-relay/openai.

Impact and severity

Talk/voice is unusable on a paired, connected iPhone even though the Gateway, command channel, permissions, and provider catalog appear healthy.

Additional information

This is related to, but distinct from, #89198 and #90952:

• Feature Request: Support Gateway TTS/STT in iOS App #89198 tracks Gateway STT/TTS support in iOS more generally. This report is a current behavior failure where iOS Talk advertises Talk commands and attempts realtime relay but the session closes before audio append.
• [Bug]: Android app pairs successfully but exposes no caps/commands and Talk voice fails (Unknown Talk session / Unknown transcription Talk session) #90952 is Android-specific and includes empty caps/commands. In this iOS repro, caps/commands are present and normal node commands work.