openclaw - 💡(How to fix) Fix [Bug]: Telegram group TTS for sub-agent reports success in /tts status but voice never delivered (2026.5.12) [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Summary

On OpenClaw 2026.5.12, TTS for a sub-agent in a Telegram group chat is broken:

• /tts status reports last_attempt: ✅ success (minimax:success(ok) with ~11s latency)
• The agent's reply includes a [[tts]] directive in the expected format
• But no voice message is delivered to the group chat
• The same sub-agent in a Telegram direct chat (DM) works correctly — voice arrives reliably

This isolates the bug to the group delivery handoff for sub-agent TTS, not to:

• TTS provider configuration (Minimax synthesis succeeds)
• Sub-agent prompt/directive output (the agent emits [[tts]] correctly)
• Telegram channel connectivity (text replies work in the same group)
• Global messages.tts.auto setting (tested with both "tagged" and "always")

Related to #65443 (DM TTS handoff bug on 2026.4.11), but specifically for group + sub-agent on 2026.5.12.

Environment

• OpenClaw version: 2026.5.12 (f066dd2)
• Channel: Telegram group (-503XXXXXXX, regular group, requireMention: true)
• Failing bot: @Little7_stock_bot (sub-agent trading)
• Working bot in DM with same config: same @Little7_stock_bot (sub-agent trading)
• Host: Ubuntu 24.04 (Kubuntu)
• Node: v24.14.0
• TTS provider: Minimax (speech-2.8-hd, female-shaonv)
• Plugins loaded: browser, canvas, device-pair, file-transfer, memory-core, minimax, openai, phone-control, talk-voice, telegram (10)

Topology

The bot setup uses one main agent + three sub-agents, each with its own Telegram bot account:

Same OpenClaw process, same config, same provider credentials, same sub-agent — only the chat type differs, and TTS only fails in the group.

Relevant configuration

messages.tts (no per-channel or per-agent overrides):

{
  "auto": "tagged",
  "provider": "minimax",
  "maxTextLength": 500,
  "timeoutMs": 30000,
  "summaryModel": "deepseek/deepseek-chat",
  "modelOverrides": {
    "enabled": true
  },
  "providers": {
    "minimax": {
      "baseUrl": "https://api.minimaxi.com",
      "model": "speech-2.8-hd",
      "voiceId": "female-shaonv",
      "speed": 1,
      "vol": 1,
      "pitch": 0
    }
  }
}

Attempting to add channels.telegram.accounts.trading.tts = { "auto": "always" } is rejected by the new schema:

Invalid config at /home/qiqi/.openclaw/openclaw.json:
- channels.telegram.accounts.trading: invalid config: must NOT have additional properties

So per-account TTS override appears to be no longer accepted in 2026.5.12 schema, although docs at https://docs.openclaw.ai/tools/tts show:

1. account override, when the channel passes channels.<channel>.accounts.<id>.tts

This may be a separate doc/schema mismatch.

Important behavioral clue

The [[tts]] marker appears verbatim in the visible group text in the failing case. Compare to DM, where [[tts]] is invisibly stripped.

This strongly suggests the group-chat code path is not entering the TTS pipeline at all, rather than entering it and failing during delivery. The directive is treated as ordinary text in groups.

If the directive were being recognized but delivery were failing, we would expect:

• [[tts]] stripped (consistent with DM)
• /tts status showing a recent failed attempt
• gateway logs showing a TTS attempt that errored

Instead we see:

• [[tts]] visible
• No recent group /tts attempt logged
• TTS provider never called for group messages

What seems most likely

A regression in 2026.5.12 (or earlier in the 2026.5.x series) in the sub-agent + group chat directive recognition path. Specifically, the directive parser/stripper appears to bypass replies originating from sub-agent accounts in group contexts.

Workarounds tried (none worked)

Related issues

• #65443 — DM TTS handoff bug on 2026.4.11 (similar symptom, different channel)
• #29637 — Telegram group messages not received after 2026.2.24
• #54695 — STT broken on Telegram since 2026.3.12
• #76627 — Telegram no response in supergroup topics (2026.5.3)

Multiple unresolved Telegram regressions in the 2026.2–2026.5 series.

Impact

• Sub-agents are unable to use TTS in any Telegram group context
• Forces users into DM-only voice workflows, breaking the main-agent + sub-agent coordination model that OpenClaw's documentation promotes for group settings
• [[tts]] directives leak into visible text, looking like a prompt formatting bug to end users

Request

Please investigate, in priority order:

1. Whether the directive parser/stripper covers replies originating from sub-agent accounts in group chats on 2026.5.x
2. Whether channels.telegram.accounts.<id>.tts is still supposed to be accepted per the docs at https://docs.openclaw.ai/tools/tts (current 2026.5.12 schema rejects it)
3. Whether group-chat replies from sub-agents are being routed through a code path that bypasses the TTS pipeline entirely

I can provide additional logs from a fresh repro if helpful — please let me know the log filters that would be most useful.

Thank you.

Steps to reproduce

Reproduction

1. Configure OpenClaw 2026.5.12 with one main agent and one trading sub-agent, each with its own Telegram bot account.

2. Set messages.tts.auto: "tagged" and messages.tts.provider: "minimax".

3. Add the trading bot (@Little7_stock_bot) to a Telegram regular group; in the same group, requireMention: true.

4. In the group, send: @Little7_stock_bot How about TSLA? (any prompt that triggers an agent reply).

5. The sub-agent responds with a message starting with [[tts]]:

   [[tts]]
   
   【Tesla, Inc. 代码TSLA】
   
    📊 买入·信心高
   
    💰 现价 443.30·MA5 附近回踩
   
    🎯 强势多头缩量回调，趋势健康
   
    ⏰ 轻仓 439 附近买入，持有者逢高减仓
   
    ⚠️ 数据 93 小时前，注意时效

   This matches the AGENTS.md TTS example format precisely ([[tts]] line, spoken line, blank line, screen text).

6. Observe: no voice message arrives in the group. The text portion (including the [[tts]] marker, which is not stripped) is sent as plain text.

7. In the same OpenClaw process, open a Telegram DM with the same @Little7_stock_bot and send the same prompt.

   → A voice message arrives correctly, alongside text. [[tts]] is stripped from visible text.

Expected behavior

When a sub-agent emits a valid [[tts]] directive in a Telegram group, OpenClaw should:

1. Strip [[tts]] and the spoken segment from visible text.
2. Send the spoken segment to the configured TTS provider (Minimax in our case).
3. Deliver the resulting audio as a voice message to the originating group chat.

This is the behavior we observe in DM with the same sub-agent.

Actual behavior

Actual behavior

In a group chat:

1. [[tts]] is not stripped — it appears verbatim in the message visible to Telegram users.
2. No voice message is delivered.
3. /tts status (run in DM, since slash commands in the group are intercepted by the sub-agent's LLM and answered with a fabricated reply rather than executed) reports the most recent successful synthesis:

   📊 TTS status
   State: ✅ enabled
   Chat override: default
   Provider: minimax (✅ configured)
   Last attempt (40467s ago): ✅
   Text: 162 chars
   Provider: minimax
   Attempt details: minimax:success(ok) 11097ms

The latest last_attempt corresponds to a DM run that succeeded; no group attempt ever produces a last_attempt: ✅.

OpenClaw version

2026.5.12

Operating system

Kubuntu 24.04

Install method

npm

Model

deepseek-v4

Provider / routing chain

openclaw -> python -> deepseek -> telegram

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response