OpenClaw Main Adds macOS Realtime Talk Relay and Fixes Blank Responses API Output

Two changes on main this cycle change what operators can build and what they should re-test: a macOS realtime relay that finally connects the native Talk app to the shared Apple Gateway transport (#128204, plus settings surfacing in #118505), and a fix for the Gateway’s OpenAI-compatible /v1/responses endpoint returning completed-but-blank or clipped answers (#128295). Both merged August 23, 2026.

macOS Talk gets the shared realtime relay

The macOS app previously could not use the bounded shared Apple Gateway realtime relay that had already landed on main. The original contributor attempt (#118499) was auto-closed when its stacked base branch was deleted, and its fork disallows maintainer edits, so maintainers landed this narrow macOS-only C layer as #128204 instead.

What the layer does:

• One pinned Gateway lease covers config lookup, relay creation, and event subscription.
• Explicit capture and output-route handling, bounded recovery, and a guarded fallback path when the native transport fails.
• Realtime bootstrap configuration is kept redacted.

Companion PR #118505 links the macOS Voice & Talk settings to the Control UI’s Talk page, keeps the configured realtime transport whenever the target provider positively advertises it, preserves the GPT-Live-specific provider-websocket exclusion, and removes only talk.realtime.consultRouting: force-agent-consult for the exact OpenAI GPT-Live + gateway-relay selection. Note that #118505 carries a needs proof label with a screenshot request in the repository’s own tracker — treat its UI-level details as landing-complete but not yet independently demonstrated.

/v1/responses stops eating answers

The second fix addresses two defects where users of the Gateway /v1/responses endpoint received either a completed response with an entirely blank answer, or streamed text missing its first buffered character (the PR names < as an example). The sibling chat-completions endpoint handled both cases correctly throughout, so only Responses-API consumers were affected.

Mechanically, the change consolidates assistant-payload text extraction across final answers, tool-call commentary, and streaming completion; applies the existing no-response diagnostic after normalization; and derives streaming append-only deltas from the authoritative cumulative snapshot, matching established chat-completions behavior. A genuinely empty model result now surfaces the visible “No response from OpenClaw.” diagnostic instead of looking like a successful empty answer.

Operator actions

• On Macs running Talk, update both the app and Gateway to builds containing #128204/#118505, then verify your provider’s realtime transport survives a settings round-trip — the settings surfacing PR is the riskier of the two for configuration drift because it actively clears routing under one specific provider selection.
• If you consume /v1/responses programmatically — wrappers, IDE plugins, eval harnesses — re-run smoke tests after upgrading. If you built workarounds for phantom-empty answers (retry-on-empty logic, response-length guards), remove them deliberately and confirm the diagnostic path now fires for true empties.
• Streaming consumers: check that first characters no longer go missing mid-stream; if you log raw deltas, compare a pre/post upgrade capture once.
• Do not expect cross-platform changes: #128204 is explicitly scoped to the macOS C layer and does not fold in the broader draft #119321 with extra settings and localization surfaces.

Interpretation note: capability claims come from the merged PR descriptions; the needs-proof caveat on #118505 is our reading of its label state at merge time. We have not lab-tested audio quality or relay latency ourselves; guidance is limited to upgrade and verification steps.