Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix WhatsApp media silently dropped: hasMedia=False on all outbound messages (2026.4.9) [1 pull requests, 3 comments, 4 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#63720•Fetched 2026-04-10 03:42:04
View on GitHub
Comments
3
Participants
4
Timeline
5
Reactions
0
Author
chengli1986chengli1986
Participants
ArtemioPadillaArtemioPadillachengli1986chengli1986kknd-brkknd-brmartingarramonmartingarramon
Timeline (top)
commented ×3cross-referenced ×1referenced ×1

Error Message

The error message from 2026.3.13 logs referenced openclaw channels login --channel web, but --channel web is not a valid channel name — possibly related to an internal channel split between inbound (personal listener) and outbound (web session)?

Fix Action

Workaround

None found. Media is silently dropped regardless of how it's sent (agent skill, CLI message send, or delivery recovery).

PR fix notes

PR #63972: fix: route to sendMedia when mediaUrl is present in dep override

Description (problem / solution / changelog)

Summary

Fixes #63720 — WhatsApp (and other channels) silently drop media attachments when sending via the message tool or CLI.

Root Cause

createChannelOutboundRuntimeSend in src/cli/send-runtime/channel-outbound-send.ts always calls outbound.sendText, even when opts.mediaUrl is provided. Since sendText ignores mediaUrl, media payloads are silently dropped on all channels that go through the dep override path.

Call chain

  1. Agent calls message tool with filePath/media ✅
  2. Gateway send handler passes mediaUrl to deliverOutboundPayloads ✅
  3. Delivery correctly identifies media, calls handler.sendMedia(caption, mediaUrl, overrides) ✅
  4. Channel outbound adapter receives mediaUrl ✅
  5. resolveOutboundSendDep returns the dep override from createLazySender → createChannelOutboundRuntimeSend
  6. Bug: sendMessage calls outbound.sendText which ignores mediaUrl ❌

Debug evidence

[outbound] payloadSummary mediaUrls=["https://..."] text=Debug test
[WA-OUTBOUND-sendMedia] mediaUrl=https://..., using=DEP-OVERRIDE
[whatsapp] Sending message -> sha256:... [mediaUrl=NONE, keys=verbose,cfg,accountId,gifPlayback]

Fix

Route to outbound.sendMedia when opts.mediaUrl is present and the adapter supports it. Falls back to sendText otherwise (unchanged behavior for text-only sends).

Impact

Affects all channels that use deliveryMode: "gateway" and go through the dep override path. Confirmed on WhatsApp; likely affects Telegram and others too.

Changed files

  • src/cli/send-runtime/channel-outbound-send.ts (modified, +16/-3)

Code Example

# Generate a test image (or use any local PNG)
openclaw message send \
  --channel whatsapp \
  --target "+86XXXXXXXXXXX" \
  --media "/path/to/image.png" \
  --message "test with media" \
  --json

---

{"module":"web-outbound"} {'jid': '...', 'hasMedia': False} sending message

---

2026-04-09T11:39:43+00:00 [web-outbound] {'jid': 'sha256:...', 'hasMedia': False} sending message  ← agent auto-reply
2026-04-09T11:41:49+00:00 [web-outbound] {'jid': 'sha256:...', 'hasMedia': False} sending message  ← manual CLI send
2026-04-09T11:46:57+00:00 [web-outbound] {'jid': 'sha256:...', 'hasMedia': False} sending message  ← another CLI send
RAW_BUFFERClick to expand / collapse

Bug Summary

openclaw message send --media <file> returns success (message ID), but the WhatsApp outbound module sends the message without the media attachment. Gateway log consistently shows hasMedia: False for every outbound message, even when --media is explicitly provided.

The recipient receives only the text; the image is silently dropped.

Environment

  • OpenClaw version: 2026.4.9 (0512059), upgraded from 2026.3.13
  • OS: Ubuntu 22.04, Linux 6.17.0-1007-aws (x64), Node 22.22.2
  • WhatsApp provider: baileys (@whiskeysockets/baileys)
  • Gateway: systemd user service, local loopback mode
  • WhatsApp status: openclaw status shows WhatsApp: ON / OK / linked

Steps to Reproduce

# Generate a test image (or use any local PNG)
openclaw message send \
  --channel whatsapp \
  --target "+86XXXXXXXXXXX" \
  --media "/path/to/image.png" \
  --message "test with media" \
  --json

Expected Behavior

Recipient receives the message with the image attached.

Actual Behavior

  1. CLI returns success with a valid messageId
  2. JSON output includes mediaUrl and mediaUrls fields correctly
  3. But gateway log shows: 
    {"module":"web-outbound"} {'jid': '...', 'hasMedia': False} sending message
  4. Recipient receives text only, no image

Evidence from Gateway Log

Every outbound message — whether sent by the agent (nano-banana-pro skill) or manually via openclaw message send --media — has hasMedia: False:

2026-04-09T11:39:43+00:00 [web-outbound] {'jid': 'sha256:...', 'hasMedia': False} sending message  ← agent auto-reply
2026-04-09T11:41:49+00:00 [web-outbound] {'jid': 'sha256:...', 'hasMedia': False} sending message  ← manual CLI send
2026-04-09T11:46:57+00:00 [web-outbound] {'jid': 'sha256:...', 'hasMedia': False} sending message  ← another CLI send

The message send CLI correctly passes the media path (confirmed via --json output showing mediaUrl), but somewhere between the gateway WebSocket handler and the baileys outbound module, the media reference is lost.

Additional Context

  • Fresh upgrade: This was tested immediately after upgrading from 2026.3.13 → 2026.4.9
  • WhatsApp text works: Plain text messages deliver successfully
  • nano-banana-pro skill: The skill's SKILL.md instructs the agent to use the message tool to send images (not MEDIA: protocol). Even when the agent follows this instruction, media is still dropped at the gateway level
  • File exists and is valid: The PNG files are confirmed accessible (1.4MB / 1.7MB, valid images)

Prior Version Behavior

On 2026.3.13, WhatsApp had a separate issue: status 440: session conflict loop that prevented all outbound (text + media). After upgrading to 2026.4.9, text delivery works but media is broken.

The error message from 2026.3.13 logs referenced openclaw channels login --channel web, but --channel web is not a valid channel name — possibly related to an internal channel split between inbound (personal listener) and outbound (web session)?

Workaround

None found. Media is silently dropped regardless of how it's sent (agent skill, CLI message send, or delivery recovery).

extent analysis

TL;DR

The issue with media attachments being silently dropped in WhatsApp outbound messages can likely be resolved by investigating and fixing the discrepancy in the hasMedia flag handling between the openclaw message send command and the gateway's WebSocket handler.

Guidance

  1. Verify media handling in the gateway: Check the gateway's code and configuration to ensure that it correctly handles media attachments and sets the hasMedia flag accordingly.
  2. Investigate the baileys library: Since the baileys library is used as the WhatsApp provider, investigate its documentation and code to see if there are any known issues or limitations related to media attachments.
  3. Check for version-specific changes: As the issue appeared after upgrading from 2026.3.13 to 2026.4.9, review the changelog and documentation for any version-specific changes that might affect media handling.
  4. Test with different media types: Try sending different types of media (e.g., videos, documents) to see if the issue is specific to images or affects all media types.

Example

No specific code example can be provided without more information about the gateway's code and the baileys library's implementation.

Notes

The issue might be related to a change in the openclaw version or a misconfiguration in the gateway. Further investigation is needed to determine the root cause.

Recommendation

Apply a workaround by temporarily downgrading to version 2026.3.13, if possible, to verify if the issue is version-specific, while also investigating the root cause of the problem in the current version.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#memory optimization#batch processing#GPU compatibility#latency issue#model loading

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING