openclaw - 💡(How to fix) Fix Add non-blocking realtime relay speech injection for async channel completions

Summary

Please consider adding an official Gateway method for speaking a short text message through an existing realtime relay session, using the same voice/provider/session that the user is already hearing.

Suggested shape:

talk.session.speak({
  sessionId: string,
  text: string
}) => { ok: true }

Internally this can call the realtime bridge sendUserMessage(text) (or an equivalent provider-neutral method) and emit a safe talk event such as completion.speech.requested.

Problem

Voice/web channels that use OpenClaw as the execution core can receive async or deferred task completions after the original realtime tool call has already returned.

Today there are two imperfect options:

1. Keep the realtime tool call open with willContinue: true and later submit the final result.

   • This preserves the realtime voice.
   • But it can block or delay subsequent response.create work while the long task is still running, which hurts natural conversation.

2. Close the tool call, track the long task externally, and speak the final completion outside the realtime session.

   • This keeps the conversation available.
   • But the channel has to use browser TTS or a separate speech provider, so the voice often sounds different from the active OpenClaw realtime voice.

For voice channels, the ideal behavior is:

• user asks naturally;
• OpenClaw accepts or starts long-running work;
• the realtime conversation remains available;
• when OpenClaw finishes, the channel can ask the same realtime session to speak the final safe user-facing summary;
• no raw task IDs, queue details, tool payloads, or technical errors are exposed to the user.

Use Case

A browser voice channel backed by OpenClaw Realtime asks OpenClaw to inspect or update a GitHub Project card. The operation may finish after the initial realtime handoff window.

The channel should be able to deliver the final result like:

Done, I moved card 12 to Cancelado.

using the same realtime voice already active in the conversation, without keeping the original tool call open and without interrupting later user turns.

Why talk.speak is not enough

talk.speak is useful as a general TTS method, but it may use a separate speech provider or voice profile. For realtime voice UX, channel completion delivery should preferably reuse the active realtime session itself.

Proposed Behavior

• Add an official descriptor and handler for talk.session.speak or similar.
• Limit it to realtime relay sessions.
• Require operator.write, same family as talk.session.submitToolResult.
• Validate sessionId and bounded text.
• Send the text into the active realtime bridge as a message to be spoken by the current voice.
• Emit a talk event with metadata only, not the full user text, to avoid logging sensitive completion content.
• Do not require a pending tool call.
• Do not block normal user conversation while background work is pending.

Notes from local validation

In a local OpenClaw 2026.5.18 deployment, a small patch adding this method allowed a browser voice channel to speak async completion updates through the active openai/gpt-realtime relay voice instead of falling back to browser speechSynthesis or a separate TTS provider.

The key design constraint is that this method should be channel-delivery only. It should not decide actions, route commands, inspect projects, or become a separate agent path.