openclaw - 💡(How to fix) Fix Telegram ordinary assistant replies can lose image attachments while text still delivers [1 participants]

Summary

Telegram ordinary assistant replies could lose image attachments even though:

• direct outbound media sends worked,
• routeReply(...) with mediaUrls worked,
• and the final user-visible reply text still arrived.

This made the bug look like a Telegram delivery problem, but it was actually in OpenClaw's internal Telegram reply pipeline.

Symptoms

In Telegram direct chat:

• direct image sends succeeded,
• standalone routeReply with mediaUrls succeeded,
• but a normal assistant reply containing text + image produced only the text part in chat.

In some cases MEDIA: was stripped from the final text, but the actual attachment was still missing.

Root cause

This ended up being a combination of bugs in OpenClaw reply processing:

1) Local markdown images were not promoted to media payloads

In dist/parse-sRKDduJ4.js, markdown image parsing only treated remote http(s) image destinations as sendable media.

That meant a normal assistant reply like:

![test](/root/.openclaw/media/tool-image-generation/example.png)

could remain text-like instead of being converted into mediaUrl / mediaUrls.

There was also a related issue in dist/agent-runner.runtime-CbAg9IpO.js: auto-parse in one reply path triggered on [[...]], MEDIA:, and NO_REPLY, but not on markdown image syntax.

2) Final payloads containing media could be dropped after block streaming

In dist/agent-runner.runtime-CbAg9IpO.js, when text had already been streamed via block replies, final payload suppression could discard a later final payload that still contained media.

That caused text already delivered to incorrectly imply media already delivered.

3) Telegram lane-splitting path returned early after sending text segments

In dist/extensions/telegram/bot-gUR32RLX.js, the Telegram normal reply path could split a payload into text lane segments.

If the payload contained both text and media, the code sent the text segments and then returned early, skipping the media send.

This was the last confirmed bug that reproduced the observed behavior: normal assistant replies with text + image delivered only text, while the image was silently lost.

Why this was confusing

The failure mode strongly suggested a Telegram API problem, but Telegram itself was fine:

• openclaw message send --channel telegram --target ... --media ... worked,
• and routeReply(...) with media also worked.

The bug was specifically in the ordinary assistant reply pipeline for Telegram.

Repro sketch

1. Use Telegram as the active channel.
2. Send a normal assistant reply that contains both text and a local/generated image, for example via markdown image syntax or a media payload derived from it.
3. Observe that the text arrives, but the image attachment may be missing.
4. Compare with a direct outbound media send to the same chat, which succeeds.

Affected areas

• dist/parse-sRKDduJ4.js
• dist/agent-runner.runtime-CbAg9IpO.js
• dist/extensions/telegram/bot-gUR32RLX.js

Suggested fix direction

1. Treat valid local markdown image destinations as media payload candidates, not only remote http(s) URLs.
2. Ensure auto-parse paths that should support markdown images actually trigger parsing for ![...](...).
3. When suppressing final payloads after block streaming, do not drop media-only or media-bearing payloads just because text fragments were already delivered.
4. In Telegram lane-splitting delivery, if text segments were emitted from a payload that also has media, explicitly send the media afterward instead of returning early.

Validation done locally

After patching the above paths and restarting the gateway:

• direct Telegram media sends still worked,
• routeReply(...) with media still worked,
• and ordinary assistant replies with inline image content finally delivered the image correctly in Telegram.