#WhatsApp group media replies fail/inconsistent while DM and manual group send work (v2026.4.11)

69 messages · Page 1 of 1 (latest)

quasi pagoda
#

Hi team, I’m hitting a WhatsApp group media issue that looks runtime-level rather than persona/config level.

What I’m trying to do:

  • Run an OpenClaw WhatsApp agent that serves both DMs and one internal WhatsApp group
  • Ask for a chart in DM or in the group
  • Agent generates the chart from SQL data and should send the image back in the same conversation

What happens instead:

  • DM works correctly: chart is generated and delivered
  • Group text replies work correctly
  • Manual CLI media send to the group JID also works correctly
  • But when the agent itself handles a normal chart request in the group, media delivery is inconsistent:
    • at different points it either sent the chart twice, sent only text/caption, or stayed silent
    • after cleaning the persona to remove OpenClaw internals, the group now replies normally to text but does not send the chart

So the failing path seems to be specifically:

  • agent-generated media as an automatic reply inside a WhatsApp group

Setup:

  • OpenClaw v2026.4.11
  • Ubuntu Server 24.04
  • dedicated WhatsApp number
  • model: openai-codex/gpt-5.4
  • local install, systemd service
  • agent workspace on disk, SQL/chart skills installed
  • DMs + groups enabled

Relevant config choices:

  • session.dmScope: "per-channel-peer"
  • session.scope: "global"
  • channels.whatsapp.dmPolicy: "pairing"
  • channels.whatsapp.groupPolicy: "open"
  • channels.whatsapp.groups."*".requireMention = true
  • plugins.slots.memory = "none"

Important observations:

  • DM chart delivery works
  • manual CLI send to the group JID works
  • group mention triggering works
  • normal group text replies work
  • the issue is only with group media delivery during a normal agent reply

Example group JID behavior:

  • inbound group logs look normal, e.g. 120363407286592856@g.us
  • manual send to that group via CLI succeeds

Question: Especially where DM media works and manual message send --media to the group works, but group auto-reply media is duplicated, dropped, or silent?

smoky palmBOT
steel cloudBOT
#

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

smoky palmBOT
oak solsticeBOT
#

You narrowed this really well. I checked the WhatsApp docs plus the runtime path, and I don’t think this is a basic group/JID/auth problem.

What the code says:

  • DM + group auto-replies share the same outbound media path once a reply exists
    processMessage → dispatchWhatsAppBufferedReply → deliverWebReply → msg.sendMedia → sendTrackedMessage
  • Manual CLI message send --media uses a different path
    createWebSendApi.sendMessage

So the fact that:

  • DM chart delivery works
  • group text replies work
  • manual group media send works

strongly suggests the break is before/around auto-reply payload delivery, not in raw WhatsApp group media sending itself.

#

The two most likely causes I’d chase are:

  1. Double delivery paths

    • one path from the chart skill/persona doing its own direct send
    • plus the normal auto-reply final payload
    • or block + final payloads both being delivered if block streaming is enabled somewhere

  2. Media only exists in a non-final payload

    • WhatsApp auto-reply currently suppresses tool payloads
    • it only delivers block and final
    • so if the chart file is generated during tool execution, but the final assistant reply is text-only, you get exactly: text reply works, chart missing

That second one matches your “after cleaning the persona, text works but chart no longer sends” symptom pretty well.

One useful narrowing: tools.media.asyncCompletion.directSend is probably not the main lever here. In current source it’s for background music/video completion, not generic SQL/chart image replies.

I’d try these next

#
  1. Force block streaming off for WhatsApp, just to eliminate duplicate block/final delivery:
{
  channels: {
    whatsapp: {
      blockStreaming: false,
    },
  },
}

Docs: https://docs.openclaw.ai/concepts/streaming

  1. Check whether the chart skill/persona is doing both

    • direct message send / explicit send
    • and also returning MEDIA: in the final reply

  2. Compare one working DM chart turn vs one failing group chart turn in verbose logs

#

Look for:

  • Reply body: ... (media)
  • Web auto-reply media source: ...
  • failed to send web media reply
  • Skipping auto-reply: silent token or no text/media returned from resolver
  1. Confirm the final assistant payload actually contains the chart
    If the media only appears in tool output and not the final payload, WhatsApp auto-reply will drop it.

Why I don’t think it’s group transport itself

There isn’t an obvious “group media send” branch in deliverWebReply. After routing, group and DM both use the same msg.sendMedia send path. That’s why manual group send succeeding is such a strong clue: the transport is fine, the auto-reply assembly/buffering path is where I’d focus.

If you paste one verbose log slice from a failing group chart request, I’m pretty confident we can tell which branch it’s hitting. Also relevant docs: https://docs.openclaw.ai/channels/whatsapp

quasi pagoda
#

Thanks, I pulled the group session JSONL and I think this confirms your direction.

What the failing group chart turn actually does:

  • the agent reads the chart skill + DB map
  • it verifies the PNG exists on disk
  • but the final assistant payload is still:
[[reply_to_current]]
MEDIA:/home/flconnect/.openclaw/workspace/exports/images/evolution_ca_ttc_2026_par_mois.png

There is no message tool call in that group turn at all.

So this seems to confirm:

  • the failure is before WhatsApp transport
  • the model/runtime is assembling an inline media auto-reply payload for the group turn
  • and the final reply path is not the same as the manual message send --media path

Other useful facts:

  • DM chart delivery works
  • manual CLI openclaw message send --channel whatsapp --target 120363407286592856@g.us --media ... works to the same group
  • normal group text replies work
  • the issue is specifically group chart/media replies generated by the agent

One thing I also noticed: the chart-mpl skill text ends with “Share the generated PNG path.” That may be nudging the model toward path-style reply behavior.

Does this now look like an auto-reply payload assembly/runtime bug in the group path? If so, is there a recommended way to force the final group reply onto the same send path as message send --media, or should this be filed as a bug?

oak solsticeBOT
#

Yeah, this looks a lot more like an auto-reply inline MEDIA: path issue than a WhatsApp group transport issue.

The big new clue is this final payload:


MEDIA:/home/flconnect/.openclaw/workspace/exports/images/evolution_ca_ttc_2026_par_mois.png

That means:

  • the model is not using message send
  • the runtime is relying on the inline auto-reply media path
  • manual CLI success is no longer the right comparison, because that uses a different send path

My take

#

Probably yes, bug-worthy, but with one last check first.

The last check I’d do is: what does the working DM turn look like in its JSONL?

If DM also ends with the same kind of inline payload:


MEDIA:/...png

and DM works while group does not, then I’d call that a pretty solid group auto-reply media bug.

If DM instead uses a different pattern, for example:

  • message tool send
  • different final text + media structure
#
  • different file path shape

then the real bug is more like fragile inline MEDIA: delivery, not specifically “group only”.

Important point

There is not a config knob I found that says “route inline auto-reply media through the same path as openclaw message send --media”.

Those are separate flows.

So today, the clean workaround is:

  1. Stop nudging the model to “share the PNG path”
  2. Change the skill/prompt to something like:
    • “Send the generated PNG back to the user”
    • “Do not reply with the raw file path”
    • “Prefer the message tool with the generated file path”
#

That chart-mpl line is absolutely pushing the model toward the most brittle path.

What I’d recommend now

Best workaround

Have the chart flow use the message tool explicitly for the image send, instead of relying on inline MEDIA:/....

Also worth doing

Compare the working DM JSONL to the failing group JSONL. That tells you whether this is:

  • true group-only bug, or
  • inline media path bug with different model behavior across chats

If DM shows the same inline payload

Then yes, I’d file it as a bug here:

https://github.com/openclaw/openclaw/issues

#

Include:

  • OpenClaw v2026.4.11
  • working manual command
  • failing final payload
  • same group JID works with manual message send --media
  • DM works
  • group text works
  • group auto-reply inline MEDIA:/...png does not

If you want, paste the DM JSONL final payload too, that’s the last piece that would make this diagnosis a lot sharper.

quasi pagoda
#

I pulled both session JSONLs and the behavior is now clear.

Working DM chart turn:

  • the agent uses the message tool
  • payload is roughly:
{
  "action": "send",
  "channel": "whatsapp",
  "target": "+212625256598",
  "filePath": "/home/flconnect/.openclaw/workspace/exports/images/evolution_ca_ttc_2026_par_mois.png",
  "caption": ""
}
  • then the final assistant text is exactly:
NO_REPLY

Failing group chart turn:

  • there is no message tool call at all
  • the final assistant payload is:
[[reply_to_current]]
MEDIA:/home/flconnect/.openclaw/workspace/exports/images/evolution_ca_ttc_2026_par_mois.png

So the difference is now explicit:

  • DM chart delivery works because it goes through message tool send
  • group chart delivery fails because it goes through inline auto-reply media assembly instead

Other confirmed facts:

  • manual openclaw message send --channel whatsapp --target 120363407286592856@g.us --media ... works to the same group
  • normal group text replies work
  • mention triggering works
  • chart generation works
  • the only broken path is group chart/media reply when the final payload is inline MEDIA:/...

At this point this looks like a runtime bug / behavior gap:

  • DM and group do not converge on the same outbound media path
  • group auto-reply falls back to inline media assembly instead of the message send path

Question:

  • Is there any supported way to force group chart/file replies onto the same outbound path as the working message tool flow?
  • Or is this bug-report worthy now?
oak solsticeBOT
#

Yep, this is bug-report worthy now.

The key distinction is:

  • DM works because the agent chose the message tool path
  • group fails because the agent chose inline MEDIA:/...
  • the runtime is not automatically converting group media replies into message send

So I’d phrase it as:

WhatsApp group auto-reply fails when the final assistant payload is inline MEDIA:/absolute/path.png, even though the same file sends successfully via message tool / manual message send --media.

Answer to your two questions

1) Is there a supported way to force group chart replies onto the message tool path?

Not with a WhatsApp channel setting, as far as I can verify.

#

I don’t see a supported “route inline media through message send” switch.

What you can do is force it at the agent/skill behavior level:

  • remove chart-mpl wording like “Share the generated PNG path.”
  • replace it with something like:
    • “Send the generated PNG back to the user using the message tool.”
    • “Do not reply with the raw file path.”
    • “After sending the file, reply only with NO_REPLY.”

That is the cleanest workaround.

2) Is it bug-report worthy?

Yes.

Because now you have a clean repro:

#
  • chart file exists
  • group triggering works
  • group text replies work
  • manual WhatsApp media send to the same 120363407286592856@g.us works
  • DM works via message tool
  • group fails specifically when final payload is inline:
    
MEDIA:/home/flconnect/.openclaw/workspace/exports/images/evolution_ca_ttc_2026_par_mois.png

That’s a solid issue.

File it here: https://github.com/openclaw/openclaw/issues

One nuance I’d include in the issue

#

I would not say “group auto-reply falls back to inline media path” unless you’ve proven the runtime made that choice.

What you’ve proven is:

  • the agent/model chose a different delivery style
  • and the inline MEDIA: group path appears broken or incomplete

That’s a cleaner bug statement.

Recommended workaround right now

Make the chart skill explicitly steer to:

  • message tool send with filePath
  • then NO_REPLY

and stop asking it to “share the PNG path”.

#

If you want, I can help you draft the exact GitHub issue text so it’s tight and reproducible.

quasi pagoda
#

Before I file an issue, can you check whether any release after v2026.4.11 already addresses this behavior?

My current version is v2026.4.11, and I noticed v2026.4.14 includes fixes around:

  • reply media normalization
  • managed outbound reply media
  • WhatsApp image send / media encryption
  • outbound session-context preservation

Given my repro:

  • DM works via message tool
  • manual message send --media to the group works
  • failing group turn ends with inline MEDIA:/...

do any of v2026.4.12, v2026.4.13, or v2026.4.14 look likely to fix this already? If yes, which one would you test first?

oak solsticeBOT
#

Short version: I’d test v2026.4.14 first, but none of the post-v2026.4.11 notes look like a clean slam-dunk for your exact auto-reply group path.

My read:

  • v2026.4.12

    • Has #64394: WhatsApp/outbound falls back to first mediaUrls entry when mediaUrl is empty.
    • That is the closest textual match to your “inline MEDIA:/... ends weirdly” symptom.
    • But it lands in the gateway/manual send path (sendMessageWhatsApp style), not the WhatsApp auto-reply deliverWebReply -> msg.sendMedia path you’ve been tracing.
    • So, possible but lower confidence for this exact repro.

  • v2026.4.13

    • I do not see a v2026.4.13 release tag.

  • v2026.4.14 / latest

    • The most relevant-looking item is the WhatsApp fix for Baileys media encryption writes / image-send ENOENT (#65896).
    • That’s more plausibly on the actual WhatsApp media send path than #64394.
    • There’s also outbound session-context replay (#66025), but that looks more about queued/recovered sends after restart, not normal live group replies.
#

One important correction:

  • The “Agents/reply MEDIA delivery: normalize local assistant MEDIA: paths ...” fix is older and appears to predate v2026.4.11.
  • So if you’re already on v2026.4.11, you likely already have that one.

Recommendation

  • If you only want one upgrade test: go straight to v2026.4.14.
  • If you want to bisect intelligently:
    1. test v2026.4.12 for #64394
    2. then test v2026.4.14 for the lower-level WhatsApp media-send fix

My confidence call

  • Most likely to help: v2026.4.14
  • Most textually similar changelog entry: v2026.4.12 #64394
  • Still likely bug-report worthy if latest fails: yes
quasi pagoda
#

Thanks, that helps. I’ll test v2026.4.14 first, and if it still reproduces there I’ll come back with a tighter report against latest.

oak solsticeBOT
#

Sounds good.

If it still repros on v2026.4.14, the most useful follow-up bundle would be:

  • openclaw --version
  • one DM success log slice
  • one group failure log slice
  • the final assistant payload for the failing turn, especially the exact MEDIA:/...
  • whether the group run logged auto-reply sent (media) vs a media failure/fallback

That should make the bug report pretty tight. If it still breaks on latest, I’m pretty confident it’s worth filing.

quasi pagoda
#

Update after testing v2026.4.14:

This is no longer just a group-vs-DM difference. After upgrading from v2026.4.11 to v2026.4.14, the DM chart turn also changed behavior.

What I now see in the DM session JSONL on v2026.4.14:

  • the agent generates the chart successfully
  • then the final assistant payload is:
MEDIA:/home/flconnect/.openclaw/workspace/exports/images/evolution_ca_ttc_2026_par_mois.png
  • there is no message tool send in that final turn

And in practice, the DM no longer delivers the chart either.

So the sharper diagnosis now seems to be:

  • auto-reply inline MEDIA:/absolute/path delivery is broken or unreliable in my setup
  • v2026.4.14 appears to make DM chart replies converge onto the same inline media path that was already problematic in groups

Summary:

  • v2026.4.11
    • DM worked via message tool
    • group failed when final payload was inline MEDIA:/...
  • v2026.4.14
    • DM final payload is now also inline MEDIA:/...
    • DM no longer delivers the chart
    • group still fails too

So this now looks less like “group-only bug” and more like a broader regression or gap in inline assistant MEDIA:/absolute/path delivery.

Would you treat this as:

  1. a bug report against latest now,
  2. or is there one more supported check you’d do first?
oak solsticeBOT
#

Yeah, I’d treat this as a bug report against latest now.

Because after v2026.4.14 the repro got cleaner:

  • chart generation succeeds
  • final assistant output is plain inline MEDIA:/absolute/path
  • both DM and group fail
  • the old “group-only” theory is gone

That points much more strongly at auto-reply inline MEDIA: delivery, not group routing, JIDs, or chart generation.

One last supported check I’d do, but I would not block on it

On v2026.4.14, send the exact same file path manually with the same WhatsApp account.

If:

#
  • manual --media /same/path.png works
  • but auto-reply final MEDIA:/same/path.png does not

then your issue is very tight:

WhatsApp auto-reply inline MEDIA:/absolute/path delivery fails/reliably drops, while manual media send of the same file succeeds.

Also include:

  • openclaw --version
  • exact final assistant payload
  • one DM repro + one group repro
  • gateway log lines around:
    • auto-reply sent (media)
    • Failed sending web media
    • any fallback text-only send
#

So my recommendation is:

  1. do that one same-file manual-send comparison on v2026.4.14
  2. then file the bug if it still reproduces, which honestly sounds very likely

If you want, I can help you word the GitHub issue so it’s crisp.

quasi pagoda
#

Confirmed on v2026.4.14:

I ran the manual same-file comparison using the exact path from the failing DM auto-reply:

openclaw message send --channel whatsapp --target +212636542585 --media /home/flconnect/.openclaw/workspace/exports/images/evolution_ca_ttc_2026_par_mois.png --message "test"

Result:

  • manual send works
  • image is delivered correctly
  • caption/text is delivered too

So the repro is now tight:

  • chart generation succeeds
  • file exists on disk
  • manual message send --media with the exact same file path works
  • but assistant auto-reply final payload MEDIA:/home/flconnect/.openclaw/workspace/exports/images/evolution_ca_ttc_2026_par_mois.png does not deliver the media

At this point I’ll file a GitHub issue against latest. Thanks — this helped narrow it down cleanly.

oak solsticeBOT
#

Nice, that’s a really solid repro.

This is the core bug statement now:

WhatsApp auto-reply inline MEDIA:/absolute/path fails on v2026.4.14, while manual openclaw message send --media <same path> succeeds with the same file and account.

A good issue title would be:

WhatsApp auto-reply inline MEDIA:/absolute/path fails, while manual message send --media with same file succeeds

Issue link: https://github.com/openclaw/openclaw/issues

If you include the final assistant payload plus one failing log slice, that should be plenty. Glad you got it narrowed down cleanly.

quasi pagoda
oak solsticeBOT
#

Perfect, thanks for filing it.

That was the right move, and the repro is nicely isolated now. If maintainers ask for one more data point, the next best thing is usually the exact failing log slice around the auto-reply media send.

If this thread helped, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.

quasi pagoda
#

even if it is not really resolved ?

oak solsticeBOT
#

Nope, not if it doesn’t feel resolved.

I’d only mark it if you think the thread reached a useful “final answer”, like:

  • confirmed bug
  • narrowed root cause cleanly
  • pointed to the right next step

If it still feels open-ended, totally fine to leave it unmarked for now.

quasi pagoda
#

someone is working on it

Fix tracked in #66689. Root cause: isAllowedAbsoluteReplyMediaPath only accepted paths under the narrow <workspaceDir>/.openclaw/media subtree, so agent-generated files placed elsewhere in the workspace (e.g. exports/images/) were silently dropped by the auto-reply pipeline. The fix widens the allow-list to include the workspace directory itself and the sandbox root as trusted roots.

https://github.com/openclaw/openclaw/pull/66689

oak solsticeBOT
#

Ah, nice, that matches your repro really well.

The key part is:

  • manual message send --media worked
  • auto-reply inline MEDIA:/... failed
  • generated file lived under exports/images/, not the narrower allowed subtree

So “silently dropped by the auto-reply pipeline because the absolute path allow-list was too narrow” is a very believable root cause.

I’d retest once a build with #66689 lands. If that fixes it, then yeah, this thread is much closer to “resolved” and worth marking.

quasi pagoda
quasi pagoda
oak solsticeBOT
#

Yep, that looks landed now.

Once it’s in the next release/nightly you can retest the exact same MEDIA:/... chart path. If it works there, this thread is a clean “fixed by #66689” story.

quasi pagoda
#

Hello I updated to the release, but we have a new issue, the media is sent twice, group and DM

oak solsticeBOT
#

Oof, that’s frustrating, but it does sound like a new bug rather than the old “dropped media” one.

First thing, can you paste:

openclaw --version

And if possible, one repro with:

  • whether it’s exactly two identical images
  • whether there is one assistant turn or two
  • the log slice around the send, especially any repeated:
    • auto-reply sent (media)
    • media fallback / retry lines

If the release fixed the missing-media bug but now sends duplicate media in both DM and group, I’d treat that as a fresh regression and probably a new issue rather than continuing the old one.

quasi pagoda
#

openclaw --version
OpenClaw 2026.4.15 (041266a)

yes two identical images, the same image, I check and found it is generated once, but sent twice

oak solsticeBOT
#

Thanks, that’s enough to call it a new regression on latest.

You’ve got:

  • OpenClaw 2026.4.15 (041266a)
  • one generated image
  • two identical media sends
  • happens in both DM and group

If the final assistant payload shows only one MEDIA:/... entry, then this is almost certainly duplicate delivery in the auto-reply path, not duplicate chart generation.

I’d file a new issue with a title like:

WhatsApp auto-reply sends inline MEDIA:/... image twice on 2026.4.15

Include:

#
  • openclaw --version
  • the final assistant payload
  • note that the image is generated once but delivered twice
  • one log slice around the duplicate send

That should be pretty actionable.

quasi pagoda
#

I will do more deep debugs and back to you so we are sure its a regression

oak solsticeBOT
#

Sounds good.

The most useful deep-debug bits will be:

  • the final assistant payload for one bad turn
  • whether it contains one or two MEDIA: entries
  • the gateway log slice around both sends
  • whether you see two auto-reply sent (media) lines or one send plus one retry/fallback path

That should tell us pretty quickly whether it’s:

  • duplicated media parsing,
  • duplicated dispatch,
  • or a WhatsApp send/retry quirk.
quasi pagoda
#

Summary of findings

  • Bug is 100% upstream in OpenClaw 2026.4.15 (041266a).
  • Mechanism: both normalizer instances fire per reply — the onBlockReply one (line 508) AND the main-reply one (line 2807 → buildReplyPayloads:1631). Each normalizer has its own persistedMediaBySource cache, so the identical input path doesn't dedupe across instances. Each invokes saveMediaBuffer("outbound") → fresh UUID each time.
  • Gating bug: onBlockReply is fed into the normalizer even when the channel's blockStreaming: false. It shouldn't be active at all for our config.
  • My side is clean — persona, skill, config, and agent behavior all verified correct.
oak solsticeBOT
#

That’s a very strong bug report. Nice work.

If your trace is showing that, then yeah, this sounds like a clean upstream regression in 2026.4.15, not a config/persona problem.

I’d put that exact summary into a new GitHub issue, or as a follow-up comment if you already opened one, especially these points:

  • single reply, single source media path
  • two normalizer instances firing
  • separate persistedMediaBySource caches
  • duplicate saveMediaBuffer("outbound")
  • onBlockReply still active even with blockStreaming: false

That should save a maintainer a lot of time. If you file it, drop the link here.

quasi pagoda
oak solsticeBOT
#

Perfect, thanks for opening it.

That thread now has a pretty solid paper trail:

  • original missing-media bug
  • fix for path allow-list
  • new 2026.4.15 duplicate-send regression
  • root-cause analysis
  • fresh issue

If this Discord thread was useful overall, it’s reasonable to mark the helpful message as solution now so Answer Overflow can index it.

quasi pagoda
quasi pagoda
oak solsticeBOT
#

Yeah, this looks very likely to be the fix for the duplicate-send regression.

Why I’m pretty confident:

  • your diagnosis was two normalizer instances handling the same MEDIA: source
  • PR #68111 is literally:

    fix: share reply media context

  • the changelog entry says:

    share one run-scoped reply media context between streamed block delivery and final payload filtering, so a local MEDIA: attachment is staged once and duplicate media sends are suppressed reliably

That maps almost perfectly to what you found.

What I’d do

  • test on the next release/nightly that includes #68111
  • rerun the same DM + group repro
  • if fixed, add a short confirmation comment on #68056
#

So, not “guaranteed” yet, but yes, this is the strongest candidate so far.

quasi pagoda
#

please give me a summary about teh whole situation drom the beginning till now

oak solsticeBOT
#

Here’s the whole thread in one clean timeline:

Summary so far

1. Original problem on v2026.4.11

You had a WhatsApp OpenClaw agent serving DMs and one WhatsApp group.

Working:

  • DM chart generation + media delivery worked.
  • Group text replies worked.
  • Group mention triggering worked.
  • Manual CLI media send to the group JID worked.

Failing:

  • Agent-generated chart/media reply inside the WhatsApp group was inconsistent:
    • sometimes duplicate media,
    • sometimes only text/caption,
#
  • sometimes silent.

Initial conclusion: not a basic WhatsApp group/JID/config issue. The likely broken path was agent auto-reply media delivery, not manual media sending.

2. First real clue: group used inline MEDIA:/...

You inspected the failing group session JSONL.

The group turn ended with:


MEDIA:/home/flconnect/.openclaw/workspace/exports/images/...

There was no message tool call.

#

By contrast, the working DM path used the message tool with a file path, then returned NO_REPLY.

So the issue became sharper:

  • DM worked because it used the message tool send path
  • group failed because it used the inline assistant MEDIA:/absolute/path auto-reply path

Workaround suggested then: steer the chart skill to explicitly use the message tool and not “share the PNG path”.

3. Upgrade to v2026.4.14

After testing v2026.4.14, the behavior changed:

  • DM also started using inline MEDIA:/absolute/path
  • DM media then failed too
  • group still failed
#

So the diagnosis shifted from:

“WhatsApp group media auto-reply bug”

to the more general:

inline assistant MEDIA:/absolute/path auto-reply delivery is broken/unreliable, while manual message send --media works.

You confirmed the exact same generated file could be sent manually, so the file itself and WhatsApp media transport were fine.

4. GitHub issue #66635

You filed:

# 
https://github.com/openclaw/openclaw/issues/66635

The tight repro was:

  • chart generation succeeds
  • file exists
  • manual openclaw message send --media <same path> succeeds
  • assistant final payload MEDIA:/absolute/path.png does not deliver media

5. PR #66689 addressed first root cause

Later, PR #66689 appeared:

# 
https://github.com/openclaw/openclaw/pull/66689

Reported root cause:

  • inline auto-reply media allow-list was too narrow
  • it only trusted a narrow .openclaw/media subtree
  • generated chart files under workspace/exports/images/ were silently dropped

So #66689 looked like the fix for the missing/dropped inline media issue.

6. New regression on v2026.4.15

After updating to OpenClaw 2026.4.15 (041266a), media no longer disappeared — but a new bug appeared:

  • same chart image was generated once
#
  • but sent twice
  • happened in both DM and group

That looked like a fresh regression, separate from the original dropped-media bug.

7. Deep-debug root cause for duplicate sends

You traced the duplicate send and found:

  • two normalizer instances handled the same MEDIA: source
  • one from onBlockReply
  • one from the main/final reply path
  • each had its own persistedMediaBySource cache
  • both called saveMediaBuffer("outbound")
  • result: same local image got staged/sent twice
#

Also important:

  • onBlockReply was still active even with blockStreaming: false

Conclusion at that point: upstream regression in 2026.4.15, not your persona/config/skill.

8. GitHub issue #68056

You filed the duplicate-send issue:

https://github.com/openclaw/openclaw/issues/68056

The issue now had a solid paper trail:

  • original missing-media bug
  • path allow-list fix
#
  • new duplicate-send regression
  • root-cause analysis

9. PR #68111 looks like the likely fix

Later, you found PR:

https://github.com/openclaw/openclaw/pull/68111

It appears to match the duplicate-send diagnosis very closely.

The key idea: share one run-scoped reply media context between streamed/block delivery and final payload filtering, so the same MEDIA: source is staged once and duplicate sends are suppressed.

Current best read from the thread:

#

#68111 is the strongest candidate fix for the duplicate media regression.

Current state / where things stand

The situation evolved like this:

  1. v2026.4.11
    Group media auto-reply failed/inconsistent; DM worked because it used message tool.

  2. v2026.4.14
    DM and group both exposed the broader inline MEDIA:/absolute/path failure.

  3. #66689
    Likely fixed the dropped inline media caused by too-narrow path allow-list.

#

  1. v2026.4.15
    New regression: media sent twice.

  2. #68056
    Filed for duplicate send regression.

  3. #68111
    Looks like the likely fix for duplicate staging/sending of reply media.

Next useful action would be: test the same DM + WhatsApp group chart repro on a release/nightly containing #68111.

quasi pagoda
#

try to make it one concise paragraph summary