Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: WhatsApp auto-reply inline MEDIA:/absolute/path fails, while manual message send --media with same file succeeds [1 pull requests, 3 comments, 3 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#66635•Fetched 2026-04-15 06:25:13
View on GitHub
Comments
3
Participants
3
Timeline
15
Reactions
0
Author
Mohamed-HAMMANEMohamed-HAMMANE
Participants
ArtyomkunArtyomkunjoelnishanthjoelnishanthMohamed-HAMMANEMohamed-HAMMANE
Timeline (top)
referenced ×6commented ×3labeled ×2closed ×1

On v2026.4.14, WhatsApp assistant auto-replies whose final payload is inline MEDIA:/absolute/path do not deliver the media, while manual openclaw message send --media <same path> succeeds with the same file and account.

Root Cause

On v2026.4.14, WhatsApp assistant auto-replies whose final payload is inline MEDIA:/absolute/path do not deliver the media, while manual openclaw message send --media <same path> succeeds with the same file and account.

Fix Action

Fixed

PR fix notes

PR #66689: fix: allow workspace-rooted absolute media paths in auto-reply

Description (problem / solution / changelog)

Closes #66635

Summary

  • When the agent generates media files directly in the workspace (e.g. <workspaceDir>/exports/images/chart.png), the auto-reply pipeline silently drops them because isAllowedAbsoluteReplyMediaPath only accepted paths under the narrow <workspaceDir>/.openclaw/media subtree.
  • This caused WhatsApp (and all other channel) auto-reply MEDIA:/path delivery to fail, while manual openclaw message send --media succeeded because it bypasses this path check entirely.
  • Widened the allow-list to include the workspace directory itself and the sandbox root as trusted roots, matching the trust boundary the agent already operates within.
  • Paths outside all trusted roots (workspace, sandbox, managed global media, OpenClaw temp dir) are still rejected.

Changes

  • src/auto-reply/reply/reply-media-paths.ts: Added workspace dir and sandbox root as allowed absolute path roots in isAllowedAbsoluteReplyMediaPath.
  • src/auto-reply/reply/reply-media-paths.test.ts: Added 3 new tests -- workspace-rooted path allowed, sandbox-rooted path allowed, paths outside all roots still dropped.

Test plan

  • All 13 tests in reply-media-paths.test.ts pass (10 existing + 3 new)
  • All 5 tests in reply-delivery.test.ts continue to pass
  • New test verifies workspace-rooted absolute path like /home/user/.openclaw/workspace/exports/images/chart.png is accepted
  • New test verifies sandbox-rooted absolute path is accepted
  • New test verifies paths outside all trusted roots (e.g. /etc/passwd) are still rejected

Risks and Mitigations

  • Risk: Widening the allow-list could permit unintended file access.
    • Mitigation: Only the agents own workspace directory and sandbox root are added -- these are already the directories the agent has full read/write access to. Paths outside all trusted roots are still blocked. The volatile-media persistence logic (buildVolatileReplyMediaRoots) is unchanged, so only the security allow-list is widened, not the persistence behavior.

-- Joel Nishanth - offlyn.AI

Changed files

  • src/auto-reply/reply/agent-runner-direct-runtime-config.test.ts (modified, +9/-0)
  • src/auto-reply/reply/agent-runner-execution.ts (modified, +9/-0)
  • src/auto-reply/reply/agent-runner.media-paths.test.ts (modified, +21/-2)
  • src/auto-reply/reply/agent-runner.ts (modified, +9/-0)
  • src/auto-reply/reply/prompt-prelude.ts (modified, +1/-1)
  • src/auto-reply/reply/reply-media-paths.test.ts (modified, +214/-82)
  • src/auto-reply/reply/reply-media-paths.ts (modified, +101/-106)
  • src/infra/outbound/message-action-params.test.ts (modified, +18/-0)
  • src/infra/outbound/message-action-params.ts (modified, +15/-3)
  • src/infra/outbound/message-action-runner.media.test.ts (modified, +1/-1)
  • src/media/load-options.test.ts (modified, +48/-2)
  • src/media/load-options.ts (modified, +24/-9)
  • src/media/read-capability.test.ts (modified, +9/-1)
  • src/media/read-capability.ts (modified, +29/-21)
  • src/plugin-sdk/outbound-media.test.ts (modified, +32/-1)
  • src/plugin-sdk/outbound-media.ts (modified, +1/-1)

Code Example

Observed final assistant payload on `v2026.4.14` in the DM session JSONL:


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


Observed result:
- the chart file exists on disk
- the media is not delivered in WhatsApp when the final assistant payload is the inline `MEDIA:/absolute/path`

Manual same-file comparison that succeeds:


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


Observed result:
- the exact same image file is delivered successfully
- the caption/text is also delivered

Additional observed context:
- normal WhatsApp text replies work
- chart generation succeeds
- the problem is specifically the auto-reply inline `MEDIA:/absolute/path` delivery path
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On v2026.4.14, WhatsApp assistant auto-replies whose final payload is inline MEDIA:/absolute/path do not deliver the media, while manual openclaw message send --media <same path> succeeds with the same file and account.

Steps to reproduce

  1. Run OpenClaw v2026.4.14 with WhatsApp configured.
  2. In a WhatsApp DM, ask the agent to generate a chart image.
  3. Confirm the chart file is generated on disk, for example: /home/flconnect/.openclaw/workspace/exports/images/evolution_ca_ttc_2026_par_mois.png
  4. Inspect the session JSONL for that turn and confirm the final assistant payload is: MEDIA:/home/flconnect/.openclaw/workspace/exports/images/evolution_ca_ttc_2026_par_mois.png
  5. Observe that the media is not delivered in WhatsApp.
  6. Run: openclaw message send --channel whatsapp --target +212600000000 --media /home/flconnect/.openclaw/workspace/exports/images/evolution_ca_ttc_2026_par_mois.png --message "test"
  7. Observe that the exact same file is delivered successfully.

Expected behavior

If the final assistant reply contains a valid inline MEDIA:/absolute/path pointing to an existing local file, WhatsApp should deliver the media, just as the same file is delivered successfully via manual message send --media.

Actual behavior

The assistant generates the chart successfully and the file exists on disk, but when the final assistant payload is inline MEDIA:/absolute/path, the media is not delivered in WhatsApp. The same file is delivered successfully when sent manually with openclaw message send --media.

OpenClaw version

2026.4.14

Operating system

Ubuntu Server 24.04

Install method

npm global

Model

openai-codex/gpt-5.4

Provider / routing chain

openclaw -> openai-codex

Additional provider/model setup details

  • Channel under test: WhatsApp
  • Host setup: local install under a dedicated Linux user, supervised by systemd
  • Effective runtime model shown in session JSONL: openai-codex/gpt-5.4
  • The issue was first observed in WhatsApp group chart replies on v2026.4.11
  • After upgrading to v2026.4.14, the DM chart flow also produced inline MEDIA:/absolute/path final payloads and DM delivery failed too
  • Manual openclaw message send --media with the same file path still works

Logs, screenshots, and evidence

Observed final assistant payload on `v2026.4.14` in the DM session JSONL:


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


Observed result:
- the chart file exists on disk
- the media is not delivered in WhatsApp when the final assistant payload is the inline `MEDIA:/absolute/path`

Manual same-file comparison that succeeds:


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


Observed result:
- the exact same image file is delivered successfully
- the caption/text is also delivered

Additional observed context:
- normal WhatsApp text replies work
- chart generation succeeds
- the problem is specifically the auto-reply inline `MEDIA:/absolute/path` delivery path

Impact and severity

Affected: WhatsApp DM and group media replies generated by the assistant

Severity: High (blocks delivery of generated chart/image replies)

Frequency: Reproduced in current testing whenever the final assistant payload is inline MEDIA:/absolute/path

Consequence: The agent can generate the requested chart, but the user does not receive the media attachment through the assistant auto-reply path

Additional information

Observed version history:

  • On v2026.4.11, the issue was first observed in WhatsApp group chart replies
  • On v2026.4.14, the DM chart flow also produced inline MEDIA:/absolute/path final payloads and DM delivery failed too

This is why I marked it as a regression: the behavior got worse across versions in my setup.

I did not find a supported config switch that forces assistant inline MEDIA:/... replies onto the same outbound path as manual openclaw message send --media.

extent analysis

TL;DR

The issue can be fixed by investigating and potentially modifying the media delivery logic in OpenClaw to handle inline MEDIA:/absolute/path payloads correctly, similar to how manual openclaw message send --media commands work.

Guidance

  1. Verify Media Path Handling: Check how OpenClaw handles media paths in auto-replies versus manual sends to identify any discrepancies.
  2. Compare Delivery Logic: Compare the logic used for delivering media in manual openclaw message send --media commands with the logic used for auto-replies containing MEDIA:/absolute/path payloads.
  3. Check for Version-Specific Changes: Since this is a regression introduced between versions, review the changelog and code differences between v2026.4.11 and v2026.4.14 to identify potential causes.
  4. Test with Different Media Types: Test the delivery of different media types (e.g., images, videos) to see if the issue is specific to certain file types.

Example

No specific code example can be provided without more details on OpenClaw's internal implementation. However, the fix might involve ensuring that the media delivery function used for auto-replies correctly interprets and sends files specified by absolute paths.

Notes

The solution might require changes to OpenClaw's source code or configuration, depending on how media delivery is implemented. The issue seems to be related to how OpenClaw handles media paths in auto-replies, which could be a bug introduced in recent versions.

Recommendation

Apply a workaround by manually sending media files using openclaw message send --media until the root cause is identified and fixed in OpenClaw's codebase. This ensures that media can still be delivered, albeit not through the auto-reply feature.

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…

FAQ

Expected behavior

If the final assistant reply contains a valid inline MEDIA:/absolute/path pointing to an existing local file, WhatsApp should deliver the media, just as the same file is delivered successfully via manual message send --media.

#memory management#API rate limit#retriever error#indexing error#inference speed

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: WhatsApp auto-reply inline MEDIA:/absolute/path fails, while manual message send --media with same file succeeds [1 pull requests, 3 comments, 3 participants]