openclaw message send --channel whatsapp --account default \
    --target +<number> --message "mp3 test" \
    --media /home/me/.openclaw/workspace/tmp/test.mp3 --json
  Result JSON includes mediaUrl + messageId, but WhatsApp receives
  text-only. Gateway log at sendMessageWhatsApp shows hasMedia:false.


### Expected behavior

Whatsapp receives voice media file.

### Actual behavior

Nothing happen

### OpenClaw version

2026.4.8

### Operating system

Ubuntu 24.04

### Install method

Install: `npm i -g openclaw`

### Model

openai-codex/gpt5.4

### Provider / routing chain

openclaw -> whatsapp

### Additional provider/model setup details

 Root cause (traced via console.error patches)

  In dist/send-Dw4UBtXk.js at the WhatsApp outbound adapter
  (createWhatsAppOutboundBase), both sendText and sendMedia wrappers
  route through:
  resolveOutboundSendDep(deps, "whatsapp",
    { legacyKeys: WHATSAPP_LEGACY_OUTBOUND_SEND_DEP_KEYS }) ?? sendMessageWhatsApp

  The gateway runtime injects a legacy deps.whatsapp shim (visible as
  depKeys: ["discord","whatsapp","cron","sendDiscord","sendWhatsapp","sendCron"]).
  Because this shim pre-dates the media-aware signature, calling it from
  the sendMedia branch drops the mediaUrl and internally routes back
  through the text-only path. Observed trace:

  [waOutboundSendMedia]  mediaUrl=/…/test.mp3  usingLegacyDep=true
  [waOutboundSendText]   (deps absent on re-entry)
  [sendMessageWhatsApp]  optKeys=[verbose,cfg,accountId,gifPlayback]   ← no mediaUrl

  So the upstream deliverOutboundPayloadsCore correctly selects the
  media branch (supportsMedia: true, summaryMediaUrls: [...]), but the
  adapter re-routes into text-only inside the WhatsApp plugin.

  Workaround / fix suggestion

  In the sendMedia wrapper of createWhatsAppOutboundBase, bypass the
  legacy dep lookup and call sendMessageWhatsApp directly (or teach the
  legacy shim to honour mediaUrl). Patching the bundled file with:

  sendMedia: async ({ cfg, to, text, mediaUrl, mediaAccess,
                      mediaLocalRoots, mediaReadFile, accountId,
                      deps, gifPlayback }) => {
    return await sendMessageWhatsApp(to, normalizeText(text), {
      verbose: false, cfg, mediaUrl, mediaAccess, mediaLocalRoots,
      mediaReadFile, accountId: accountId ?? void 0, gifPlayback
    });
  }

  immediately restores media delivery (verified end-to-end: mp3 arrives on
  WhatsApp, (media) tag appears in outbound log, send takes ~1.8s vs
  ~240ms for text).

  The same resolveOutboundSendDep pattern exists in sendText — should
  likely be removed there too if the legacy shim path is no longer
  intended to be used, or the shim should be updated.

  Impact

  Any media send via WhatsApp (agent tool message, CLI message send,
  broadcast with --media) is silently text-only. Gateway returns success
  with a messageId, so upstream callers / agents cannot detect the loss.


### Logs, screenshots, and evidence

```shell