Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On OpenClaw 2026.5.7, cron jobs with --announce delivery report delivered: true in cron runs, but the message never arrives on the channel. Reproduced on both openclaw-weixin (WeChat) and feishu channels.

This appears to be a live reproduction of #78532 — deliverySucceeded returns true when no channel adapter was actually invoked.

Environment

• OpenClaw: 2026.5.7 (eeef486)
• Node: v24.14.0
• OS: Linux aarch64 (Docker container, kernel 6.12.76-linuxkit)
• Install: npm global
• Gateway: local container, WebSocket
• Channels tested: openclaw-weixin, feishu

Reproduction

We ran three test rounds to isolate the issue:

Test 1: Cron with --announce, default agent (glm-4.7)

openclaw cron add \
  --name "test-cron-v1" \
  --at "2026-05-09T16:01:00+08:00" \
  --message "Cron test message" \
  --session isolated \
  --tools exec \
  --timeout-seconds 60 \
  --announce \
  --channel openclaw-weixin \
  --account <account-id> \
  --to "<wechat-target>" \
  --delete-after-run

Result: cron runs shows status: ok, delivered: true, fallbackUsed: true. Message never arrived on WeChat.

Test 2: Cron with --announce, specific agent (glm-5.1)

Same setup with --agent a and all channel/account/target specified explicitly.
Result identical: delivered: true, fallbackUsed: true, no message received.

Also tested with feishu channel — same result: delivered: true, message never arrived.

Test 3: Cron with --no-deliver, agent sends via openclaw message send ✅

openclaw cron add \
  --name "test-cron-v3" \
  --at "2026-05-09T16:44:00+08:00" \
  --agent a \
  --message "...use exec to call openclaw message send directly..." \
  --session isolated \
  --tools exec \
  --timeout-seconds 120 \
  --no-deliver \
  --delete-after-run

Result: Agent successfully called openclaw message send via exec, message arrived immediately. ✅

Cron runs evidence (Test 1)

{
  "status": "ok",
  "delivered": true,
  "deliveryStatus": "delivered",
  "delivery": {
    "resolved": {"ok": true, "channel": "openclaw-weixin", "to": "<target>", "accountId": "<account>", "source": "explicit"},
    "fallbackUsed": true,
    "delivered": true
  },
  "model": "glm-4.7",
  "provider": "zai",
  "durationMs": 53435,
  "usage": {"input_tokens": 9506, "output_tokens": 337, "total_tokens": 9710}
}

openclaw message send works correctly

Direct CLI send succeeds and message arrives instantly:

openclaw message send --channel openclaw-weixin --target <id> --message "test"
# ✅ Sent via openclaw-weixin. Message ID: openclaw-weixin:1778315656966-8ce21c73

Expected behavior

Cron --announce delivery should deliver the message to the configured channel, or report a clear failure if delivery was not actually performed.

Actual behavior

Cron reports delivered: true with fallbackUsed: true but the message never arrives. The channel adapter was never actually invoked. openclaw message send to the same channel/target works fine.

Root cause (likely)

This matches #78532: deliverOutboundPayloads exits early without invoking a channel adapter (via the announce/fallback path), and deliverySucceeded = !deliveryHadError defaults to true since no error was set. The announce delivery pipeline appears to hit an early return path that skips actual adapter invocation.

Workaround

Use --no-deliver on the cron job and have the agent call openclaw message send directly via exec in its response. This bypasses the broken announce fallback delivery pipeline and messages arrive correctly.

Additional context

This was also observed on OpenClaw 2026.4.9 with WeChat, suggesting the announce delivery issue has persisted across multiple releases.

Related issues: #78532, #77260, #78608

OpenClaw version

2026.5.7

Operating system

Linux (Docker, aarch64)

Install method

npm global

Model

glm-5.1 / glm-4.7

Provider / routing chain

zai/glm-5.1 → gateway

Impact and severity

Cron-based automation appears to complete successfully (status ok, delivered true) but messages silently disappear. This makes scheduled notifications and reminders completely unreliable without manual verification.