Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Describe the bug

When an agent outputs MEDIA:<path> tags for generated images/voice messages, Telegram receives each attachment twice, while the Web UI correctly shows only one delivery.

This affects non-streaming Telegram bot accounts (streaming mode is off for the affected agent).

To Reproduce

1. Configure an agent with streaming: "off" on Telegram channel
2. Use a plugin tool that generates media (e.g., TTS audio, generated images)
3. Agent outputs MEDIA:<audioPath> and/or MEDIA:<imagePath>
4. Observe Telegram delivers each attachment twice

Expected behavior

Each MEDIA: tag delivers the attachment exactly once, matching the Web UI behavior.

Diagnostic evidence

• Trajectory confirms model outputs MEDIA once: assistantTexts: ["MEDIA:/path/to/voice.ogg\nMEDIA:/path/to/image.jpg"]
• didSendViaMessagingTool: false, messagingToolSentTexts: [] — no duplicate from message tool
• Plugin's built-in delivery has RUNTIME_CAPABILITY_MISSING, falls back to MEDIA tag
• Web UI shows single delivery; only Telegram shows duplicates

Environment

• OpenClaw: 2026.5.4 (325df3e)
• OS: macOS 26.2 (arm64)
• Node: v22.22.1
• Channel: Telegram (bot token, polling mode)
• Streaming: off (per-agent override)

Version regression

This issue was not present in v2026.4.27. It was likely introduced in v2026.4.29 (major agent reply runtime restructuring), potentially worsened by v2026.5.2 ("tighten Telegram delivery/recovery behavior").

v2026.5.4's fix "Agents/media: avoid sending generated attachments twice when streamed reply text arrives before final MEDIA directive" only covers streaming scenarios and does not resolve this non-streaming case.

Related issues

• [Bug]: MEDIA: directive delivers voice/audio messages twice on all channels (4.15) #70085 — same root cause pattern on WhatsApp: "duplicate delivery from separate reply-media normalizer instances/caches between block delivery and final reply delivery"
• Bug: MEDIA directive causes duplicate file delivery in Discord channel #68475 — Discord MEDIA duplicate delivery

Steps to reproduce

1. Configure an agent with streaming: "off" on Telegram channel
2. Use a plugin tool that generates media (e.g., TTS audio, generated images)
3. Agent outputs MEDIA:<audioPath> and/or MEDIA:<imagePath>
4. Observe Telegram delivers each attachment twice

Expected behavior

Each MEDIA: tag should result in exactly one attachment delivered to the Telegram chat:

• MEDIA:/path/to/image.jpg → Telegram receives the image once
• MEDIA:/path/to/voice.ogg → Telegram receives the voice once
• No duplicate file deliveries in chat history
• Behavior identical to Web UI, which delivers attachments only once

Actual behavior

Each MEDIA: tag results in attachments being delivered twice on Telegram:

• MEDIA:/path/to/image.jpg → Telegram receives the image twice (two photo messages appear in chat)
• MEDIA:/path/to/voice.ogg → Telegram receives the voice twice (two voice messages appear in chat)
• This happens for both image and audio media types, not limited to one format
• The issue is consistent across multiple requests — every media generation triggers double delivery
• Plugin's built-in delivery mechanism shows RUNTIME_CAPABILITY_MISSING and correctly falls back to MEDIA: tag, ruling out the plugin itself as the source of duplication
• Web UI shows only one delivery per attachment, confirming the problem is Telegram-channel-specific

OpenClaw version

2026.5.4 (325df3e)

Operating system

macOS 26.2

Install method

No response

Model

DeepSeek V4 Flash

Provider / routing chain

openclaw -> DeepSeek

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response