openclaw - 💡(How to fix) Fix Cron + Discord: agentTurn with explicit delivery.to is sent 2-3x when visibleReplies=automatic [2 pull requests]

Summary

When a cron agentTurn job targets a Discord channel and the channel-session has messages.visibleReplies: automatic (default), a single assistant turn can result in 2-3 Discord messages being posted instead of one.

Repro

OpenClaw 2026.5.10-beta.3 (commit 6d7dcd9).

Config:

• messages.visibleReplies: "automatic"
• messages.groupChat.visibleReplies: "automatic"
• Discord plugin (@openclaw/discord)

Cron job:

{
  "schedule": { "kind": "at", "at": "<iso>" },
  "sessionTarget": "session:agent:main:discord:channel:1503132078122995814",
  "payload": {
    "kind": "agentTurn",
    "message": "Post a short message to Carro in this channel ..."
  },
  "delivery": {
    "mode": "announce",
    "channel": "discord",
    "to": "1503132078122995814"
  },
  "deleteAfterRun": true
}

Run-history shows delivery.messageToolSentTo listing the same channel multiple times with different to formats:

"messageToolSentTo": [
  { "channel": "discord", "to": "1503132078122995814" },
  { "channel": "discord", "to": "channel:1503132078122995814" },
  { "channel": "discord", "to": "channel:1503132078122995814" }
]

…and three identical messages actually appear in the Discord channel within a few seconds.

Expected

Exactly one Discord message per assistant turn, regardless of whether the run was triggered by:

• An inbound user message routed via visibleReplies: automatic, OR
• A cron job with explicit delivery.to.

Actual

The assistant turn is delivered via both code paths:

1. Automatic visibleReplies echoes the assistant text to the source channel.
2. The cron delivery.to re-sends the same text to the explicit target.
3. The Discord plugin's message-tool path also seems to retry with normalized to (channel:<id> vs raw id), producing a third copy.

Notes

• 100% reproducible in the affected setup.
• Also observed: cron job failures auto-announce as ⚠️ Cron job "<name>" failed: ... to the delivery channel. This is sometimes desired, but there's no obvious knob to make the failure announcement go to a different (private) channel than the success delivery.
• The fail-announcement is delivered even when the cron's agentTurn produced an empty assistant turn but the underlying provider call technically succeeded (output_tokens: 3, "Agent couldn't generate a response").

Suggested fixes

• When delivery.to is explicit on a cron job, suppress automatic visibleReplies for that turn (or vice-versa, document the priority).
• De-duplicate messageToolSentTo targets after normalization (<id> and channel:<id> should resolve to the same dedupe key).
• Allow failureAlert to be a separate destination from delivery (the schema hints at this; verify it works in practice for cron announce deliveries).

Env

• macOS 25.2.0 / arm64, node v25.9.0
• Channel: Discord guild 1466160679496056935, channel 1503132078122995814