openclaw - ✅(Solved) Fix [Bug]: openclaw message send --dry-run still delivers the message via gateway [1 pull requests, 1 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#66549Fetched 2026-04-15 06:25:40
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
Participants
Timeline (top)
cross-referenced ×1

openclaw message send --dry-run ... has documented behavior: "Print payload and skip sending (default: false)". Actual behavior: the message is printed AND delivered to the target channel.

Root Cause

openclaw message send --dry-run ... has documented behavior: "Print payload and skip sending (default: false)". Actual behavior: the message is printed AND delivered to the target channel.

Fix Action

Workaround

  • Avoid --dry-run entirely on this command
  • Use --json to inspect the serialized payload
  • Or use a dedicated test target (test account) for validation

PR fix notes

PR #66559: fix(cli): implement proper dry-run behavior for message send command

Description (problem / solution / changelog)

Fixes #66549

The --dry-run flag was not being honored in the message send command. The flag only affected progress spinner visibility but the message was still sent to the target channel.

Root cause: messageCommand() calls runMessageAction() regardless of dryRun flag value.

Changes

  • Add conditional logic to skip runMessageAction() when dryRun is true
  • Return mock result with messageId: 'dry-run' for dry-run mode
  • Add test case verifying dry-run doesn't call gateway
  • Preserve existing behavior for non-dry-run executions

Impact

--dry-run now safely prevents message delivery as documented, fixing automation safety issues

Testing

✅ All existing tests pass ✅ New test validates dry-run prevention

Changed files

  • extensions/telegram/src/bot-message-context.audio-transcript.test.ts (modified, +22/-0)
  • extensions/telegram/src/bot-message-context.body.ts (modified, +1/-1)
  • extensions/telegram/src/bot-message-context.session.ts (modified, +2/-2)
  • src/agents/bash-tools.exec-approval-followup.test.ts (modified, +19/-0)
  • src/agents/bash-tools.exec-approval-followup.ts (modified, +7/-3)
  • src/auto-reply/reply/reply-payloads-base.ts (modified, +1/-4)
  • src/auto-reply/reply/reply-plumbing.test.ts (modified, +14/-0)
  • src/commands/message.test.ts (modified, +47/-0)
  • src/commands/message.ts (modified, +21/-10)

Code Example

openclaw message send \
  --channel whatsapp \
  --target "+5511999999999" \
  --dry-run \
  --message "TEST — should not be delivered"
RAW_BUFFERClick to expand / collapse

Summary

openclaw message send --dry-run ... has documented behavior: "Print payload and skip sending (default: false)". Actual behavior: the message is printed AND delivered to the target channel.

Environment

  • OpenClaw version: 2026.3.28 (commit f9b1079)
  • Platform: WSL2 Ubuntu 24.04 on Windows 11
  • Channel tested: whatsapp (via internal gateway)

Reproduction

openclaw message send \
  --channel whatsapp \
  --target "+5511999999999" \
  --dry-run \
  --message "TEST — should not be delivered"

Expected

  • CLI prints the constructed payload for inspection
  • No actual delivery to the target channel
  • Exit 0

Actual

  • CLI prints ✅ Sent via gateway (whatsapp). Message ID: unknown
  • Message IS delivered to the target WhatsApp number (confirmed by recipient)
  • The Message ID: unknown return value is the only subtle signal that something was different, but the recipient receives the message as a normal send

Impact

Any script or skill that uses --dry-run as a safe validation mode will inadvertently spam the configured channel. Particularly risky for:

  • Automated pre-flight checks in cron-backed flows (nightly audit/reporter-style skills that construct payloads and dry-run them before real dispatch)
  • Integration tests that exercise CLI commands without wanting real delivery
  • Any tooling that builds user confidence on --dry-run being safe

Discovered this unintentionally while wiring a direct openclaw message send call from a Python orchestrator — the dry-run variant shipped a test message to a real WhatsApp recipient.

Workaround

  • Avoid --dry-run entirely on this command
  • Use --json to inspect the serialized payload
  • Or use a dedicated test target (test account) for validation

Suspected scope

The --dry-run flag is declared in message send options and visible in --help, so argument parsing is registering it. The issue likely lives in the gateway dispatch path — the flag is probably not being threaded through to the "skip delivery" branch in the message-tool module. Quick win if someone knows that codepath.

extent analysis

TL;DR

The --dry-run flag in openclaw message send is not preventing message delivery as expected, and a workaround is to avoid using this flag and instead use --json to inspect the payload or a dedicated test target for validation.

Guidance

  • Verify that the issue persists across different channels and platforms to determine if it's specific to the whatsapp channel or WSL2 Ubuntu 24.04 environment.
  • Inspect the openclaw codebase to confirm that the --dry-run flag is being properly parsed and passed to the message-tool module.
  • Consider using a debugging tool or logging mechanism to trace the execution path of the openclaw message send command and identify where the --dry-run flag is being ignored.
  • Evaluate the feasibility of implementing a temporary fix, such as modifying the openclaw code to properly handle the --dry-run flag, until an official patch is released.

Example

No code snippet is provided as the issue is related to the behavior of the openclaw command and not a specific code implementation.

Notes

The root cause of the issue is suspected to be in the gateway dispatch path, where the --dry-run flag is not being properly threaded through to the "skip delivery" branch. However, without access to the openclaw codebase, it's difficult to provide a more detailed analysis.

Recommendation

Apply workaround: Avoid using the --dry-run flag and instead use --json to inspect the payload or a dedicated test target for validation, as this approach allows for safe testing without inadvertently sending messages to production channels.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING