openclaw - 💡(How to fix) Fix Telegram outbound audio replies lack a way to force sendAudio/sendVoice from normal assistant MEDIA replies [1 participants]

Summary

OpenClaw clearly supports Telegram audio sending internally, including sendVoice, asVoice, audioAsVoice, and the [[audio_as_voice]] reply tag. However, from a normal assistant reply path using MEDIA: / generic media reply payloads, there does not appear to be a reliable way to force Telegram to send media as sendAudio or sendVoice.

In practice, this means an assistant can generate an MP3 successfully, but the normal reply surface may only emit a text/file reference instead of a playable Telegram audio attachment, and there is no exposed way in standard assistant replies to specify media kind.

Why this matters

For Telegram, there is an important distinction between:

• sendAudio → regular playable audio attachment / music player UI
• sendVoice → round voice-note bubble UI
• sendDocument → generic file card

OpenClaw already knows about this distinction internally, but the generic outbound reply payload appears too lossy to preserve it.

What I verified locally

Installed OpenClaw docs/code on 2026.03.x show:

• Telegram docs explicitly mention:
  • default audio file behavior
  • [[audio_as_voice]] to force voice-note send
  • message action example using action: "send", channel: "telegram", media, asVoice: true
• Built code includes:
  • replyWithAudio
  • replyWithDocument
  • replyWithVoice
  • asVoice
  • audioAsVoice
  • [[audio_as_voice]]
• Built code also includes attachment-kind detection helpers such as:
  • resolveAttachmentKind
  • isAudioAttachment
  • isAudioFileName

So the capability exists in pieces.

The gap

The shared outbound reply payload used by ordinary assistant replies appears to only preserve something like:

• text
• mediaUrl / mediaUrls
• replyToId

But not:

• media kind
• MIME hint
• asVoice
• audioAsVoice in a way that is accessible from ordinary MEDIA: reply usage for regular audio files

As a result, the Telegram sender cannot reliably distinguish:

• audio attachment
• voice note
• generic document

for ordinary assistant-delivered media replies.

Reproduction

1. Generate an MP3 file locally in an assistant session.
2. Reply with a normal assistant media reference such as:
   • MEDIA:./morning-briefing-2026-03-24.mp3
3. Expectation:
   • Telegram should receive a playable audio attachment, ideally via sendAudio for MP3.
4. Actual result:
   • Depending on surface/runtime, the user may get only a text/path reference or a non-playable/generic file-style result.
   • There is no obvious first-class way from the standard assistant reply surface to force sendAudio.

Expected behavior

One of these should work from normal assistant replies:

Option A: richer reply payload

Allow assistant replies to preserve media metadata, e.g.

• mediaKind: "audio" | "voice" | "document" | "image" | "video"
• MIME/content type
• audioAsVoice: true

Option B: reliable Telegram inference

When the outbound media path sees:

• .mp3 / .m4a → use sendAudio
• .ogg / .opus with voice intent → use sendVoice

Option C: explicit directive support for audio file vs voice note

Support reply-level directives that survive normalization, for example:

• [[audio_as_voice]] for voice-note send
• perhaps a parallel explicit directive for audio-file send if needed

Suggested fix

At minimum, Telegram outbound media delivery should be able to distinguish between:

• audio file attachment
• voice note
• generic document

for ordinary assistant-produced media replies.

The cleanest fix is probably to extend the shared outbound payload model so it carries media type / send intent explicitly instead of collapsing everything to generic mediaUrl.

Nice-to-have

If the message action path already supports this correctly (action: "send", media, asVoice: true), it would be great if normal assistant reply paths had an equivalent way to express the same thing without requiring access to a separate message-action tool surface.