openclaw - 💡(How to fix) Fix [Bug]: WhatsApp final reply MEDIA: directive can render as plain text for PDF/document attachments

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On OpenClaw 2026.5.20, a WhatsApp group auto-reply completed with a final assistant message containing a MEDIA:<local-pdf-path> directive. The WhatsApp user received the raw MEDIA: directive as visible assistant text instead of receiving the PDF as a document attachment.

The same PDF sent successfully to the same WhatsApp group using openclaw message send --media, so the WhatsApp media upload/send path was working. The failure appears to be in the final assistant reply directive parsing or handoff into WhatsApp media delivery.

This looks related to the older locked issue #78578, but that issue was closed as not reproducible on current main and cannot accept new comments. It is also adjacent to #83584, but this report is about the WhatsApp channel, not the OpenAI-compatible HTTP surfaces.

Steps to reproduce

This was observed in production; identifiers and local paths are redacted.

1. Run a WhatsApp group auto-reply agent on OpenClaw 2026.5.20 (e510042870).

2. Have the agent generate a PDF/document artifact as part of its final reply.

3. The final assistant response includes a line of the form:

   MEDIA:<redacted local PDF path>

4. Observe the WhatsApp group receives that raw MEDIA: line as normal text instead of a PDF/document attachment.

5. Send the same PDF to the same WhatsApp group explicitly:

   openclaw message send --channel whatsapp --account <account> --target <group> --media <same-pdf> --message <caption>

6. Observe that the explicit media send succeeds and the PDF appears in WhatsApp.

Expected behavior

A final assistant reply MEDIA: directive should be parsed and stripped from visible text, then dispatched to WhatsApp as a media/document attachment.

If the attachment cannot be sent, the user should receive an explicit channel-visible error that does not expose the raw local path. The raw directive should not appear in the chat as ordinary assistant text.

Actual behavior

The raw MEDIA:<local-pdf-path> directive appeared as visible WhatsApp text. No PDF/document attachment was sent from the auto-reply final response.

An explicit openclaw message send --media with the same PDF to the same group succeeded immediately, which isolates the problem away from the underlying WhatsApp media upload path.

OpenClaw version

2026.5.20 (e510042870)

Operating system

Ubuntu 25.10

Install method

Live source checkout with systemd-managed gateway

Model

openai-codex/gpt-5.5

Provider / routing chain

WhatsApp group inbound auto-reply → OpenClaw embedded runtime → openai-codex auth profile → Codex app-server → WhatsApp outbound delivery

Additional provider/model setup details

The provider/auth profile was healthy during the incident. A direct no-delivery smoke test against the same agent/runtime succeeded, and subsequent explicit WhatsApp media sends succeeded.

Logs, screenshots, and evidence

Redacted evidence from the recovery window:

final assistant reply included: MEDIA:<redacted local PDF path>
WhatsApp displayed the MEDIA line as plain text
explicit openclaw message send --media <same-pdf> returned a WhatsApp media message id and the PDF arrived

One additional cleanup error appeared after successful explicit media sends:

ENOENT: no such file or directory, lstat '<openclaw delivery queue>/<redacted>.json'

That may be incidental, but it occurred in the same attachment recovery window.

Impact and severity

Severity: High for report/document workflows over WhatsApp.

Generated files can fail to arrive even though the channel media path works, and the raw MEDIA: directive can expose host-local path information to the WhatsApp user. This is especially painful when the user requested generated reports or review packets and expects the attachment to be delivered automatically.

Additional information

Related prior issue: #78578 reported WhatsApp agent-authored MEDIA: directives not dispatching while openclaw message send --media worked, but it is closed/locked and was reviewed as not reproducible on current main. This production trace is on a newer build and specifically involves a PDF/document attachment in a WhatsApp group final reply.