Summary

Isolated cron sessions do not inherit the messaging channel from the cron config; they silently default to a wrong channel (e.g. WhatsApp instead of Slack), causing notifications to be delivered to the wrong place unless every message() call explicitly passes channel=.

Steps to reproduce

1. Configure an OpenClaw agent with multiple channels (e.g. Telegram + Slack).
2. Create a scheduled cron with sessionTarget: "isolated" and a payload that calls message(action=send) without an explicit channel parameter.
3. Observe which channel receives the message.

Expected behavior

The isolated cron session should either (a) inherit the messaging channel from the cron config or the agent's primary channel, or (b) require channel as a mandatory cron-level setting and fail with a clear error if omitted, rather than silently defaulting to the wrong channel.

Actual behavior

The message is delivered to a fallback/default channel (e.g. WhatsApp) instead of the intended one (e.g. Slack). There is no error or warning — the notification silently lands in the wrong place. Every message() call in the cron session must explicitly pass channel="slack" (or the intended channel) to work correctly, placing a hidden requirement on the LLM to remember the channel on every call.

OpenClaw version

2026.2.19-2 (45d9b20)

Operating system

Debian Linux 6.12.63+deb13-amd64 (x64)

Install method

npm global

Logs, screenshots, and evidence

Impact and severity

• Affected: Any multi-channel OpenClaw deployment using isolated cron sessions (sessionTarget: "isolated")
• Severity: Medium — notifications silently reach the wrong channel with no error
• Frequency: Always when channel is not explicitly passed in every message() call
• Consequence: Missed Slack/channel notifications, unexpected messages on unintended channels (e.g. WhatsApp), requires every LLM agent call to remember the correct channel name or notifications are silently lost

Additional information

No response