#OpenClaw with WhatsApp auto-reply.Media not delivered and direct send command

1 messages · Page 1 of 1 (latest)

tribal bloom
#

Hi — I’m testing OpenClaw with WhatsApp auto-reply.

I’m seeing this behavior:

  • normal text auto-replies work
  • MEDIA: in normal replies falls back to text only (mediaUrl: null, mediaKind: null in logs)
  • real reactions / direct send actions are not available to the agent in the auto-reply session
  • docs/code suggest the message tool is preferred for media, but the group auto-reply prompt also says:
    “Your replies are automatically sent to this group chat. Do not use the message tool to send to this same group - just reply normally.”

Question:
Is there a supported way to keep/expose the message tool (send, react) inside WhatsApp auto-reply sessions, especially for same-chat delivery?
Or is this intentionally disabled in auto-reply flows?

Context:

  • OpenClaw 2026.4.21
  • WhatsApp channel connected and working for text
  • goal is to allow media sending and real reactions from the agent in the same chat/group
brave merlinBOT
teal oceanBOT
#

Short answer: this looks like a prompt/docs mismatch, not a hard auto-reply disable.

What the code is doing on 2026.4.21:

  • message is not intentionally removed from auto-reply sessions by default. Auto-reply embedded runs still build the normal OpenClaw tool set, including message.
  • For the current channel, send is always part of the message tool schema.
  • For WhatsApp, react is only exposed when both are true:
    • channels.whatsapp.actions.reactions: true
    • channels.whatsapp.reactionLevel: "minimal" or "extensive"
      ("ack" and "off" disable agent-initiated reactions)

Also, same-chat behavior is supported in code:

  • message.send can default to the current chat if no target is provided.
  • WhatsApp react can default to the current inbound message id in same-chat auto-reply context.

So there is no separate “keep/expose message tool in auto-reply” switch that I found. If it is missing in your session, I’d suspect tool policy filtering instead, for example:

#
  • global/per-agent tools.allow / tools.deny
  • per-group WhatsApp tool policy under channels.whatsapp.groups...tools

For the MEDIA: issue, the likely cause is this:

  • inline normal replies do support MEDIA:
  • but local media is normalized through a safety filter
  • if the path is blocked, it gets dropped and you end up with text-only delivery

Common cases that get dropped:

  • file://...
  • ~/...
  • ../...
  • absolute paths outside the allowed file-read boundary / workspace
  • other host-local paths the agent is not allowed to stage

So mediaUrl: null / mediaKind: null is consistent with media being stripped before outbound delivery, not with media replies being unsupported.

#

Practical guidance:

  • For inline replies, use:
    • MEDIA:https://...
    • or a safe workspace-relative path like MEDIA:./out/image.png
  • If you need local file sending from outside that boundary, use the message tool with media / path / filePath
  • If react is missing, check:
    • channels.whatsapp.actions.reactions
    • channels.whatsapp.reactionLevel
    • any group/global tool policy hiding message

So I’d summarize it as:

  1. Same-chat message tool use is supported, not globally disabled.
  2. The group auto-reply prompt saying “don’t use the message tool for this same group” is advisory/preference, mainly to keep normal text replies in the built-in reply pipeline.
  3. Inline MEDIA: is supported but stricter than the prompt makes obvious, so blocked local paths fall back to text-only.
tribal bloom
#

Hi — quick follow-up with concrete results.

I updated the WhatsApp config to:

json
"actions": {
"reactions": true
},
"reactionLevel": "minimal"

and restarted OpenClaw.

Current behavior:

  • text auto-replies work
  • group replies now work more broadly
  • but the agent still does not appear to have the message tool / react action exposed in the auto-reply session
  • inline MEDIA: also still falls back to text-only, including a safe workspace-relative path:
    MEDIA:./out/openclaw-media-test.jpg

So at this point:

  • WhatsApp reactions config is enabled
  • but agent-initiated react still isn’t available in-session
  • and inline MEDIA: still gets stripped before outbound delivery

Question:
What else controls exposure of the message tool in auto-reply sessions?
Is there another tool policy / runtime profile / per-channel gate that needs to be enabled?

teal oceanBOT
#

Yep, there’s another gate, and I think this is the big one:

Most likely culprit: tools.profile

If your config has:

tools: {
  profile: "coding",
}

then message is excluded on purpose.

In current docs/code, profiles work like this:

  • coding includes fs/runtime/web/etc, but not message
#
  • messaging includes message
  • you can also keep coding and add messaging back with allow: ["group:messaging"]

So this is a very plausible explanation for:

  • text auto-replies still working
  • message / react not appearing in-session
  • WhatsApp reaction config being correct, but still not visible to the agent

reactionLevel + actions.reactions only control whether WhatsApp react is discoverable once the message tool is available. They do not force the message tool to exist.

Other gates that can hide it

Check these too:

  • tools.profile
  • tools.allow / tools.deny
#
  • tools.byProvider[...]
  • agents.list[].tools.*
  • agents.list[].tools.byProvider[...]
  • channels.whatsapp.groups.<groupJid>.tools
  • channels.whatsapp.groups.<groupJid>.toolsBySender

Also, there is one hard runtime gate:

  • local embedded mode / no gateway
    In that mode, code explicitly marks message as unavailable.

What I’d try first

If you want to keep your normal coding/runtime tools and just add messaging:

# 
{
  tools: {
    profile: "coding",
    allow: ["group:messaging"],
  },
}

If you use a specific agent for auto-reply, do it on that agent instead.

About MEDIA:./out/openclaw-media-test.jpg

That is separate from the message tool issue.

MEDIA: should work, but only if the file is readable from the actual auto-reply agent workspace / sandbox at reply time. A safe relative path is only safe if the file really exists there.

#

So if it still gets stripped, the next useful thing is the full log line, especially the one starting with:

  • dropping blocked reply media ...

That line should tell us whether it’s:

  • path policy
  • file missing
  • sandbox/workspace mismatch

My read of the current state

  • message is not enabled by WhatsApp reaction config alone
  • tools.profile: "coding" is a very likely reason it stays hidden
  • the group prompt saying “don’t use the message tool” is guidance, not the real hard gate, and honestly a bit misleading here

If you paste these three config sections, I can tell you pretty quickly what’s blocking it:

tribal bloom
#

Quick follow-up with test results after config changes:

I updated config to include:
json
"tools": {
"profile": "coding",
"allow": ["group:messaging"]
},
"channels": {
"whatsapp": {
"actions": {
"reactions": true
},
"reactionLevel": "minimal"
}
}

and restarted OpenClaw.

Still seeing:

  • no visible in-session message / react capability from the agent side
  • inline MEDIA: still falls back to text-only

Tested examples:

None arrived as media.

So now I’m trying to determine:

  1. whether message is still being hidden by another tool/runtime gate
  2. or whether WhatsApp auto-reply same-chat delivery is still restricted to normal text replies in practice
  3. and separately why MEDIA: is still stripped even for a workspace-relative path

Any idea what exact gate or log I should inspect next?

teal oceanBOT
#

I think you’re looking at two separate gates, not one:

  1. Tool availability (message, react)
  2. Normal-reply MEDIA parsing + staging

Short version, the prompt text is guidance, not the hard gate. If message survives runtime tool filtering, same-chat send/react is allowed in principle. I’d trust /tools over that prose.

What to check next

1. In the actual WhatsApp auto-reply session, run /tools verbose
That is session-scoped and shows the effective tool inventory right now.

  • If message is missing entirely, it is being filtered before prompting.
  • The next places to inspect are:
    • tools.byProvider.*
    • agents.<id>.tools.*
    • channels.whatsapp.groups["..."].tools
#
  • channels.whatsapp.groups["..."].toolsBySender
    • agents.defaults.experimental.localModelLean (this also drops message)

Docs: https://docs.openclaw.ai/channels/groups
FAQ: https://docs.openclaw.ai/start/faq

2. If message is present, but react is not
Then the likely gate is WhatsApp action discovery, not the base tool.

Check gateway logs for:

  • [message-action-discovery] whatsapp.actions.describeMessageTool failed
  • WhatsApp reactions are disabled
  • WhatsApp agent reactions disabled

Also confirm the effective account has:

  • channels.whatsapp.actions.reactions: true
#
  • reactionLevel: "minimal" or "extensive"

(If you use WhatsApp accounts, make sure the effective account is the one getting those settings.)

3. For inline MEDIA:
Your log line mediaUrl: null, mediaKind: null means the media was probably dropped before WhatsApp send, in the reply normalization path.

The exact verbose log to look for is:

  • dropping blocked reply media ...

If it survives that stage, you should then see:

  • Web auto-reply media source: ...
  • and later auto-reply sent (media)

Important MEDIA gotchas

#
  • MEDIA: needs to be on its own line (not prose, not code fences)
  • MEDIA:/tmp/... is often dropped because it is outside the agent’s allowed read boundary
  • MEDIA:./out/... is resolved relative to the agent workspace / sandbox, not the gateway’s cwd
  • file://... is explicitly blocked for normal replies

So:

  • if /tmp/... fails, that can be expected
  • if ./out/... fails, I’d suspect workspace mismatch or group policy denying read
  • if even a clean MEDIA:https://... line fails, I’d suspect parser/output shape, or the model never emitted a clean directive line

My best guess

Given your symptoms, I’d check in this order:

  1. /tools verbose in the WhatsApp session
  2. gateway logs for [message-action-discovery]
#
  1. verbose logs for dropping blocked reply media

If you paste:

  • /tools verbose output from that session, and
  • the few log lines around either dropping blocked reply media or [message-action-discovery]

I can narrow it down pretty fast.

tribal bloom
#

Quick test result from my side:

I asked the assistant to send a plain external image using:

MEDIA:https://upload.wikimedia.org/wikipedia/commons/3/3f/JPEG_example_flower.jpg

If that still arrives as text-only / stripped, then this strongly suggests the issue is not just local file path policy. It would point more toward one of these:

  • normal auto-reply MEDIA directives are not being promoted to WhatsApp media sends in this runtime/session path
  • same-chat WhatsApp reply flow is text-only in practice for this route
  • MEDIA normalization/parsing is getting dropped before provider send, even for clean HTTPS input

So at that point the split would be:

A. Tool/capability issue

  • explains missing message / react
  • likely session/runtime filtering

B. MEDIA delivery issue

  • independent from local file access
  • because even HTTPS would be failing

The most useful logs to inspect next would be around:

  • dropping blocked reply media
  • Web auto-reply media source:
  • auto-reply sent (media)
  • [message-action-discovery]

And I’d still want the effective session-scoped result of:
/tools verbose

because if that session still shows 0 tools, then the tool side is definitely being filtered before prompt construction.

My current read:

  • groups policy was one real issue
  • 0 tools in DM is another real issue
  • MEDIA failing for HTTPS too would confirm a third, separate issue in reply media handling or provider path

If you want, I can help draft the exact “here are the logs/config sections I need” follow-up too.

teal oceanBOT
#

Yep, I think your split is right.

My read from current source:

  • message is not intentionally disabled in WhatsApp auto-reply just because the prompt says “reply normally”.
  • Normal WhatsApp auto-replies do have a media send path (deliverWebReply resolves media and calls WhatsApp sendMedia), so this does not look intentionally text-only in code.

So if clean HTTPS MEDIA: still gets stripped, I’d treat that as a separate bug/gate, not expected behavior.

What I’d inspect next

1. Effective tools in that exact session

Run this inside the affected WhatsApp auto-reply session:

/tools verbose
#

That is the authoritative runtime view.

If message is missing there, the filtering is happening before prompt construction. The main suspects are:

  • tools.byProvider.*
  • agents.<id>.tools.*
  • channels.whatsapp.groups.*.tools
  • channels.whatsapp.groups.*.toolsBySender
  • agents.defaults.experimental.localModelLean

If message is present but react is not, then it’s likely the WhatsApp action discovery side.

2. Logs during one clean HTTPS repro

From the FAQ/troubleshooting path, I’d do:

# 
openclaw status --all
openclaw logs --follow

Then reproduce with exactly:

MEDIA:https://upload.wikimedia.org/wikipedia/commons/3/3f/JPEG_example_flower.jpg

The key log lines are:

  • dropping blocked reply media ...
  • Web auto-reply media source: ...
  • auto-reply sent (media)
  • [message-action-discovery] ...
#

3. How to interpret the logs

  • If you see dropping blocked reply media

    • media was rejected before WhatsApp send

  • If you never see Web auto-reply media source:

    • parser/normalization/staging likely dropped it before provider send

  • If you see Web auto-reply media source: but not auto-reply sent (media)

    • WhatsApp/provider send path is failing

  • If /tools verbose shows no message

    • tool-side filtering is definitely still active somewhere

What I’d want pasted next

Sanitized output for:

#
  • a reaction discovery/account-config mismatch,
  • or a real reply-media bug on 2026.4.21.