TTS Voice Note Delivery Regression in v2026.4.9

Fri, 10 Apr 2026 00:00:00 +0000

Symptom

After upgrading to OpenClaw v2026.4.9, TTS (text-to-speech) voice note delivery is completely broken:

Outbound TTS (Voice Notes from Assistant):

User sends a text message to the assistant via Telegram
Assistant calls tts tool with channel: "telegram"
Tool returns Generated audio reply
Expected: Voice note delivered to user
Actual: Only text response received; no voice note

Inbound STT (Voice Notes to Assistant):

User sends a voice note to the assistant via Telegram
Expected: Audio transcribed and processed
Actual: No transcription; pdf tool fails with “Expected PDF but got audio/ogg”, image tool fails with “Unsupported media type: audio”

Evidence from logs:

Gateway logs show no TTS-related events after the tts tool call
No sendVoice API calls are made to Telegram
Text messages continue to work correctly (proving Telegram connectivity is intact)

Historical logs show the last sendVoice attempts failing: telegram sendVoice failed: Network request for ‘sendVoice’ failed! telegram final reply failed: HttpError: Network request for ‘sendVoice’ failed!

Root Cause Analysis

The investigation reveals that the tool→channel delivery handoff is broken:

ElevenLabs API is functioning correctly — Audio files are successfully generated by the tts tool
Tool reports success — Generated audio reply message confirms audio creation
Broken handoff — The audio file is never passed to the gateway’s Telegram channel
No sendVoice call — No Telegram API call is initiated to deliver the voice note
Regression introduced in v2026.4.9 — The change from pre-v2026.4.9 behavior (corrupted delivery) to v2026.4.9 (no delivery) indicates a code regression in how the tts tool result is handled by the channel delivery layer

Pre-v2026.4.9 behavior: TTS generated audio but it was corrupted (appearing as long strings of exclamation marks in webchat).

v2026.4.9 behavior: TTS generates audio but delivers nothing at all.

The shift from “corrupted delivery” to “no delivery” suggests the audio file handling code path was either removed or broken during the v2026.4.9 update.

Solution

This is a code regression bug that requires a fix in the OpenClaw codebase. The following steps are needed:

Restore the sendVoice call path in the channel delivery layer — Ensure the audio file generated by the tts tool is properly passed to sendVoice for Telegram delivery
Verify audio file handling — Confirm the audio file path/content is correctly transferred between the tool result handler and the Telegram sender
Add integration tests for TTS→Telegram delivery to prevent future regressions
Fix STT handling — Ensure inbound voice notes are properly recognized and routed to the STT pipeline instead of being rejected as unsupported media types

Temporary Workaround:

Users may attempt to use the message tool with explicit media path for file attachment (untested)

Prevention

To prevent similar regressions in future releases:

Add automated TTS integration tests — Create end-to-end tests that verify voice notes are actually delivered to Telegram (not just that the tool reports success)
Test the full delivery pipeline — Ensure both generation AND delivery are tested together, not in isolation
Monitor channel delivery layer changes — Any modifications to how tool results are processed should include regression testing for media delivery
Log delivery confirmation — Add explicit logging when sendVoice is called to make failures more visible in logs
Multi-channel testing — Test TTS functionality when multiple channels (Telegram + webchat) are active simultaneously, as session handling issues may compound the problem

Additional Information

Affected versions: OpenClaw v2026.4.9 (updated 2026-04-09) and potentially later versions
Previous working behavior: Pre-v2026.4.9 had corrupted audio delivery
TTS Provider tested: ElevenLabs (eleven_multilingual_v2)
Channel: Telegram
Network connectivity: Confirmed working (text messages deliver successfully)
API credentials: ElevenLabs credentials verified functional via manual API calls
Multi-session factor: Session handling issues may contribute when Telegram and webchat are used simultaneously

Sources

GitHub Issue #64272