How to Send OpenClaw Messages from the CLI

openclaw message is for outbound channel actions. It does not ask the model to think; it sends, reads, reacts, edits, pins, polls, or performs channel-specific actions through configured providers. That distinction matters. If your automation needs literal delivery, use message. If it needs reasoning first, use openclaw agent and optionally deliver the answer.

When this is the right move

Use message send for reminders, deployment notifications, status pings, support acknowledgements, and scripted channel posts. It is especially helpful when cron, CI, or a shell script needs to notify a real chat surface without going through a model turn. Keep it explicit in multi-channel setups because channel and target formats differ by provider.

The practical workflow

1. Pick the channel. The docs say --channel is required when multiple channels are configured, and supported values include Discord, Google Chat, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, and WhatsApp, with Mattermost via plugin.
2. Use the target format for that provider. Slack accepts channel:<id>, user:<id>, or a raw channel id; Discord has channel and user forms; Telegram can use chat id or username; WhatsApp uses E.164 or group JID.
3. Send text with --message, or use media/presentation fields where supported.
4. Use --thread-id or --reply-to only on providers that support those fields. Slack thread replies use thread timestamps, while Telegram forum topics use topic ids.
5. Use --dry-run before wiring a new automation to a real channel.

Grounded command or config pattern

The exact target format is the part to get right. Store stable channel IDs in your local notes instead of relying on names in production scripts.

openclaw message send --channel slack --target channel:C123456 --message "Deploy finished"
openclaw message send --channel telegram --target @username --message "Reminder"
openclaw message read --channel slack --target channel:C123456 --limit 5
openclaw message send --channel slack --target channel:C123456 --thread-id 1712345678.000100 --message "Thread reply"

The message CLI resolves supported channel SecretRefs only for the selected action target when possible. That means unresolved secrets on unrelated channels should not block a targeted send, but the selected channel/account must still resolve or the command fails closed.

Operator notes

Message actions are broader than send. The official reference includes poll, react, reactions, read, edit, delete, pin, unpin, permissions, search, thread create/list/reply, emoji actions, role/member/channel info, events, and moderation for providers that support them. Build automations against the documented action support, not against wishful cross-platform parity.

Rollout approach

For send openclaw messages from the cli, I would make the first pass deliberately small: one owner, one machine or channel, one visible test, and one rollback path. OpenClaw features become powerful when they connect to real tools and real messages, so the safest rollout is not a giant configuration day. It is a short rehearsal that proves the docs-grounded path works in your exact workspace before you depend on it while busy.

Common mistake

The common mistake is treating the command as the whole feature. The command starts the workflow, but the surrounding state is what keeps it reliable: config validation, auth, pairing, permissions, logs, and a tiny verification step. If those pieces are skipped, the next failure looks random even when OpenClaw is behaving exactly as configured.

Maintenance rhythm

Once this is working, write down the exact command, config path, or approval decision you used. Future you will not remember the tiny detail that made the setup safe. A small note in the workspace or runbook is cheaper than rediscovering the same behavior during an outage, especially after updates or machine changes.

Safety checks

Outbound messaging is an external side effect. Use dry runs, stable IDs, and explicit channels. Avoid name-based targets in critical automations unless you trust the directory cache/live lookup behavior. For Slack and Discord threads, always pass the thread id explicitly; ambient context is not something a standalone CLI command can infer safely.

How to verify it worked

A successful command should return cleanly, and the target channel should show the intended message or action. For automations, log the command result and enough channel/message identifiers to debug later without scraping chat history manually.

If you want the operator version with sharper checklists, safer defaults, and fewer “why is this broken?” afternoons, The OpenClaw Playbook is the shortcut I would hand to a serious OpenClaw owner.