#Why can't whatsapp send a media file now?

1 messages · Page 1 of 1 (latest)

rare smelt
#

Previously, Whatsapp was able to send .md files attached to the message. Now it can't, what is the reason? Is it model specific? I changed from Anthropic to Openrouter.

shell groveBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

unborn cipherBOT
#

Not really model-specific — WhatsApp attachments are handled by the Gateway + WhatsApp (Baileys) channel, not by Anthropic vs OpenRouter.

Two common causes when “.md used to work, now doesn’t”:

  1. MIME type / filetype rejection on WhatsApp
  • OpenClaw infers the MIME type from the extension.
  • .md → text/markdown
  • WhatsApp Web/Baileys can be picky about document mimetypes, and text/markdown may get rejected (while text/plain usually works).

Workarounds:

  • rename the file to .txt (or something.md.txt) before sending
  • zip it (.zip) and send that
  • or have the agent send the content inline (if it’s small)
  1. Your new model stopped emitting the required MEDIA: line correctly
    If you’re asking the agent to “send a file”, the outbound attachment only happens if the final assistant text includes a line exactly like:
#

MEDIA:/absolute/or/relative/path/to/file.md

(on its own line, not inside a code block). Some OpenRouter models are worse at sticking to that exact output format.

What I need to tell which one it is

Can you paste:

  1. openclaw --version
  2. the log lines from openclaw logs --follow right when it tries to send the .md (you’ll usually see something like “Failed sending web media …”)

Docs refs:

rare smelt
#

I can't attach, can you help me to understand how to handle media files?

unborn cipherBOT
#

Media sending in OpenClaw is mostly a channel/Gateway thing, not an Anthropic vs OpenRouter thing. The model only affects whether the assistant formats the reply in a way that triggers an attachment.

Here’s the mental model + the practical ways to do it.

1) The 2 ways to send media

A) Send media directly via CLI (best for testing)

On the gateway machine:

openclaw message send --channel whatsapp \
  --target +15551234567 \
  --message "here you go" \
  --media /path/to/file.txt

If this fails, it’s definitely not the model.

#

B) Have the agent send media (requires a MEDIA: line)

For auto-replies/agent replies, OpenClaw will attach files only if the assistant output contains a line like this (must be on its own line, not inside a code block):

MEDIA:/absolute/or/relative/path/to/file.png

So if you switched models and the model stopped emitting that exact MEDIA: line, you’ll see “no attachment”.

2) Where the file must live (common gotcha)

When you attach a local path, that file must exist on the gateway host, and it must be inside allowed roots.

By default, local media paths are allowed under (roughly):

  • /tmp
  • ~/.openclaw/media
  • ~/.openclaw/agents (agent/session/workspace outputs)
#

So a reliable pattern is:

  • copy files you want to send into ~/.openclaw/media/
  • then attach from there.

If you try to attach something like ~/Downloads/foo.md it may be blocked with an error like:
“Local media path is not under an allowed directory …”

3) Why .md specifically often breaks on WhatsApp

OpenClaw detects .md as MIME text/markdown. WhatsApp Web / Baileys can be picky about document mimetypes, and text/markdown may get rejected even though text/plain works.

Workarounds:

  • rename file.md → file.txt (forces text/plain)
  • or zip it (file.zip)
  • or paste the content inline if it’s small

4) Quick debug checklist

#
  1. Try CLI send (section 1A) with a .txt first.
  2. Tail logs while sending:
    openclaw logs --follow
  3. Look for errors like:
    • local media path not allowed
    • media exceeds size cap
    • WhatsApp send failure / disconnected socket

If you paste the log snippet from the moment it fails (and your openclaw --version), I can tell you which of the above you’re hitting.

Docs:

rare smelt
#

How can I ensure that the agent is able to send a media file?

unborn cipherBOT
#

To “guarantee” media sending, you want to make sure all 4 layers line up:

1) The agent must output a real attachment trigger

OpenClaw only attaches files if the assistant response contains a MEDIA: token on its own line and not inside a code block.

Good:

Here you go.

MEDIA:/tmp/report.txt

Bad (won’t be parsed because it’s in a fenced block):

```text
MEDIA:/tmp/report.txt
# 
```

If the path has spaces, quote it:

MEDIA:"/tmp/My Report.txt"

2) The file must exist on the Gateway host

If your Gateway runs on a VPS, then /tmp/foo.png must exist on the VPS (not your laptop).

3) The file path must be allowed (security)

By default OpenClaw only allows local attachments from safe roots like:

  • /tmp
  • ~/.openclaw/media
  • ~/.openclaw/agents/...
#

So the most reliable workflow is: put outbound files in ~/.openclaw/media/ and attach from there.

4) Size + filetype must work for WhatsApp

Two frequent “it used to work” failures:

Size cap (very common)

Auto-replies are capped by agent config: agents.defaults.mediaMaxMb (default is often 5MB).

If you’re trying to send bigger docs/images, bump it in your ~/.openclaw/openclaw.json:

{
  agents: {
    defaults: {
      mediaMaxMb: 20,
    },
# 
  },
}

Restart the gateway after config changes.

.md files specifically

.md maps to MIME text/markdown, and WhatsApp Web/Baileys can reject that sometimes.

Workarounds:

  • rename .md → .txt before sending, or
  • zip it (.zip), or
  • send a .pdf

Best “make it reliable” approach

If your model sometimes forgets the MEDIA: line (some OpenRouter models do), don’t rely on formatting—use the CLI to test, because it bypasses the model entirely:

# 
openclaw message send --channel whatsapp \
  --target +15551234567 \
  --message "here you go" \
  --media ~/.openclaw/media/file.txt

If that works but the agent doesn’t, it’s almost always: MEDIA: line formatting (wrong place / inside code fence), or .md MIME weirdness.

If you paste the exact agent reply text it produced + the log snippet from openclaw logs --follow when it tries to send, I can point to the precise failure.

rare smelt
#

Response from bot:

"I understand you want the file attached. As I've explained, due to the limitations of the messaging platform, I cannot send actual file attachments directly in a way that would appear as a downloadable .md file in this chat.

When I tried to use the media parameter for attaching, I received an error stating that local media paths are not allowed.

The best I can do is provide the content of the article as formatted text, which I've done previously.

If you need the article content for a specific purpose where copy-pasting the text would work, please let me know."

unborn cipherBOT
#

That bot reply is a bit misleading: OpenClaw can send WhatsApp attachments. What you hit is a local-file security guard, not a “WhatsApp can’t do it” limitation.

Why you got “local media paths are not allowed”

When the assistant tries to attach MEDIA:/some/local/path, the Gateway will only read local files from a small set of allowed directories (to prevent prompt-injection/file exfiltration).

By default, local attachments must live under one of these roots:

  • /tmp
  • ~/.openclaw/media
  • ~/.openclaw/agents/... (agent workspace/session outputs)

If your agent pointed at something like ~/Downloads/file.md or /Users/.../Desktop/..., it will be blocked.

How to ensure the agent can send a file (reliable recipe)

  1. Write/copy the file into an allowed folder (recommended: ~/.openclaw/media/)
#
  1. Have the agent output a MEDIA: line with that path (not in a code block), e.g.
Here you go.

MEDIA:/home/<user>/.openclaw/media/article.txt

If the path has spaces, quote it:

MEDIA:"/home/<user>/.openclaw/media/My Article.txt"
  1. Avoid .md for WhatsApp if it’s flaky
    WhatsApp/Baileys can reject text/markdown. Quick workaround: rename to .txt (or zip it).