openclaw - 💡(How to fix) Fix [Bug] Isolated cron session delivery fails with 'Channel is required' even when delivery.channel is explicitly set [1 participants]

Bug Description

When a cron job uses sessionTarget: "isolated" with delivery.mode: "announce" and explicitly sets delivery.channel, delivery.to, delivery.accountId, and delivery.bestEffort: true, the delivery still fails with:

Channel is required (no configured channels detected). Set delivery.channel explicitly or use a main session with a previous channel.

Environment

• OpenClaw version: 2026.4.2
• Node: v22.22.1
• OS: Linux 6.8.0-101-generic (x64)
• Channel: wecom (enterprise WeChat bot, WebSocket mode)

Steps to Reproduce

1. Configure a cron job with the following settings:

{
  "sessionTarget": "isolated",
  "payload": { "kind": "agentTurn", "message": "..." },
  "delivery": {
    "mode": "announce",
    "channel": "wecom",
    "to": "wecom:SXF7526",
    "accountId": "default",
    "bestEffort": true
  }
}

1. Wait for the cron job to trigger automatically (not manually via dashboard)
2. The agent completes successfully and generates a summary, but delivery fails

Observed Behavior

• Manual trigger (via OpenClaw dashboard "Run" button): delivery succeeds ✅
• Automatic trigger: delivery fails with Channel is required ❌

The difference appears to be that manual triggers inherit the active session's channel context, while auto-triggered isolated sessions start completely fresh and cannot resolve the delivery channel from the job configuration alone.

Expected Behavior

When delivery.channel is explicitly set, the delivery layer should resolve the channel from the global channel registry, regardless of whether the session has prior channel context.

Workaround

Using sessionTarget: "main" + payload.kind: "systemEvent" works because the main session always has channel context.

Logs

[cron:d9adc227-...] Channel is required (no configured channels detected). Set delivery.channel explicitly or use a main session with a previous channel.

Channel plugin is running normally — multiple successful outbound messages via wecom-outbound are visible in the same log file.