Summary

When an assistant reply contains MEDIA: directives for local image paths in a Telegram direct chat, the Telegram adapter can send the reply as a plain text message instead of attaching the images. The visible result is that the user receives literal MEDIA:/path/to/file.jpg lines and no photos/documents.

Environment

• OpenClaw app: 2026.5.3
• OS: macOS 26.3 arm64
• Channel: Telegram direct chat
• Gateway: local LaunchAgent

Repro

1. Have a Telegram direct conversation with OpenClaw.
2. Create local images inside an allowed OpenClaw path, e.g.:
   • /Users/.../.openclaw/workspace/neetware-pfps/example.jpg
   • /Users/.../.openclaw/media/generated/neetware-pfps/example.jpg
3. Reply from the assistant with one or more standalone MEDIA: lines, e.g.:

MEDIA:/Users/.../.openclaw/media/generated/neetware-pfps/example.jpg

or multiple:

MEDIA:/Users/.../.openclaw/media/generated/neetware-pfps/a.jpg
MEDIA:/Users/.../.openclaw/media/generated/neetware-pfps/b.jpg
MEDIA:/Users/.../.openclaw/media/generated/neetware-pfps/c.jpg

Expected

Telegram should deliver the files as photo/document attachments, using sendPhoto / sendDocument as appropriate, and strip the MEDIA: directive lines from the visible text.

Actual

Telegram sends a normal text message containing the literal MEDIA: lines. Gateway logs show sendMessage ok; no corresponding sendPhoto or sendDocument call appears for these replies.

Diagnostics / likely root cause

I checked the local docs and runtime behavior:

• Docs say local-path MEDIA: attachments can use absolute paths, workspace-relative paths, or ~/ paths, subject to file-read/media type checks.
• The outbound parser correctly extracts these local paths. Running OpenClaw’s normalized payload path on the same text produced:

[
  {
    "text": "",
    "mediaUrls": [
      "/Users/.../.openclaw/media/generated/neetware-pfps/a.jpg",
      "/Users/.../.openclaw/media/generated/neetware-pfps/b.jpg",
      "/Users/.../.openclaw/media/generated/neetware-pfps/c.jpg"
    ]
  }
]

• However, Telegram delivery appears to make the preview/finalization decision using resolveSendableOutboundReplyParts(payload, { text }) before parsing inline MEDIA: directives out of text.
• Because the raw payload has text but no payload.mediaUrls yet, the Telegram path treats it as text-only and chooses the preview/edit or sendMessage path. The media parser never gets a chance to turn those MEDIA: lines into attachments for that final send.

Relevant local areas inspected:

• docs/reference/rich-output-protocol.md
• docs/start/openclaw.md media section
• dist/deliver-*.js / outbound payload planning: createOutboundPayloadPlanEntry(...) parses directives correctly
• dist/bot-*.js Telegram finalization path: hasMedia = resolveSendableOutboundReplyParts(payload, { text }).hasMedia seems to be evaluated on unparsed text
• dist/delivery-*.js Telegram send path only saw text payloads in this case

Suggested fix

Before Telegram decides whether a final reply can be edited/sent as text-only, normalize/parse reply directives so MEDIA: lines contribute to mediaUrls. In other words, the hasMedia check in Telegram preview/finalization should use the same directive-parsed payload that delivery later uses, not the raw text-only payload.

This should prevent MEDIA: replies from going through the sendMessage/preview path and ensure they reach the media delivery path.