Summary

After upgrading to OpenClaw 2026.3.22, Telegram voice reply behavior is unstable:

1. Voice replies intermittently arrive as audio file cards (MP3-style UI) instead of voice-note bubbles.
2. Outbound Telegram sends intermittently fail with Channel is unavailable: telegram, then recover seconds later.

This happens even when we explicitly force voice-note routing in replies.

Environment

• OpenClaw: 2026.3.22
• Host: Linux (jarvis, loopback gateway)
• Channel: Telegram DM
• Config (effective during tests):
  • messages.tts.auto: off (manual route)
  • messages.tts.provider: openai
  • messages.tts.mode: final
  • messages.tts.openai.model: gpt-4o-mini-tts
  • messages.tts.openai.voice: onyx
  • channels.telegram.enabled: true

What we tested

• A/B paths with/without force markers (including explicit voice-note forcing in assistant reply path)
• Provider variants (OpenAI / Microsoft Opus config)
• messages.tts.auto modes (always, inbound, off)
• Manual sequencing (voice then text summary)

Actual behavior

• Some replies render correctly as voice-note bubbles.
• Other replies in same session/flow render as audio file cards.
• Intermittent errors in gateway logs:
  • message failed: Channel is unavailable: telegram
• Recovery is often immediate/near-immediate (next send succeeds).

Evidence (recent logs)

From journalctl --user -u openclaw-gateway.service --since '2 hours ago':

• 2026-03-23T16:00:27 → message failed: Channel is unavailable: telegram
• 2026-03-23T16:00:31 → message failed: Channel is unavailable: telegram
• 2026-03-23T16:04:16 → message failed: Channel is unavailable: telegram
• 2026-03-23T16:04:24 → immediate success sendMessage ok ... message=13361
• 2026-03-23T16:06:22 → success sendMessage ok ... message=13363

This pattern repeats throughout the session (brief unavailable spikes amid successful sends).

Expected behavior

• If voice-note is forced, Telegram should consistently use sendVoice delivery semantics (voice bubble UI) rather than occasionally degrading to audio-file card.
• Transient channel unavailability should have robust retry/fallback behavior with clear classification and logging.

Impact

• User-facing inconsistency in core voice UX (bubble vs file card)
• Perceived unreliability after update
• Operational confusion during troubleshooting because behavior flips within same config/session

Related issues

Potentially related historical reports:

• Telegram: Voice messages sent as audio files instead of voice bubbles #11654 (voice delivered as audio files)
• Telegram: voice message silently dropped when caption exceeds limit #6068 (voice/caption behavior with auto mode)
• Telegram channel broken after upgrading to 2026.3.x — undici bypasses macOS TUN/VPN #33013, Telegram Channel Network Request Failures with IPv6 Environment #21043, [Bug]: Telegram channel fails with 404 - $VARIABLE references in botToken not resolved (v2026.3.2) #34247 (Telegram transport/connectivity regressions in 2026.3.x family)

Request

Please investigate Telegram send-path selection and fallback behavior in 2026.3.x:

• Ensure forced voice-note path stays deterministic
• Improve resilience and observability around transient Channel is unavailable: telegram
• Clarify whether fallback to sendAudio can occur under specific failure/retry branches