How to Use OpenClaw Reactions

OpenClaw reactions are small, but they matter. A reaction can acknowledge a message without adding another reply, mark a handoff, or show that an agent saw something. The docs describe reaction behavior through the message tool with action react. The basic shape is message id plus emoji, with remove behavior varying by channel.

30-second answer

Use the message tool’s react action with messageId and emoji to add a reaction. Set remove true to remove a specific emoji. In several channels, an empty emoji removes the bot’s reactions, but exact behavior differs across Slack, Discord, Google Chat, Telegram, WhatsApp, Zalo Personal, Feishu/Lark, and Signal.

Channel differences

Slack and Discord support removing all of the bot’s reactions with an empty emoji and removing one specific emoji with remove true. Google Chat behaves similarly for the app’s reactions. Telegram can remove bot reactions, but remove true still requires a non-empty emoji for validation. WhatsApp maps remove true to an empty emoji internally while still requiring emoji in the tool call.

Special cases

Zalo Personal requires a non-empty emoji, and remove true removes that specific reaction. Feishu/Lark uses a separate feishu_reaction tool with add, remove, and list actions. Signal reaction notifications are controlled by channel config: off disables them, own emits events when users react to bot messages, and all emits events for all reactions.

Reaction level

Some channels expose reactionLevel config with values such as off, ack, minimal, or extensive. Use that to tune how often an agent reacts. In team spaces, I prefer ack or minimal. Extensive reactions can become noise quickly unless the channel culture expects them.

Good automation

Use reactions for low-stakes signals: “seen,” “queued,” “done,” or “needs attention.” Do not use reactions as the only record for irreversible actions. If a workflow changed production, took payment action, or made a public post, send an actual message with the outcome.

Playbook angle

The Playbook approach is to use reactions as social grease, not as a reporting system. They should reduce chat noise without hiding important operational state.

Runbook checklist

Before you automate this, run one small acceptance test with harmless input. Confirm the tool is available to the right agent, the credential is loaded from config or environment, the output shape matches the workflow, and the failure message is understandable to a tired operator. If the feature touches money, public channels, logged-in browsers, host commands, or customer data, put a review step before the side effect. If it only reads data, still record the source and timestamp so future sessions do not treat stale context as fresh truth. Keep the first version narrow, then expand once the logs show the agent is choosing the right tool for the right reason. When the docs are incomplete, prefer a conservative sentence over a clever invented shortcut that future agents cannot reliably verify. Add one monitoring habit as well: after the first real run, check the transcript or logs for missing prerequisites, broad prompts, stale assumptions, and accidental side effects. Tighten the instruction while the failure is fresh. The best OpenClaw workflows improve in small, documented passes instead of one giant rewrite after something breaks in public. For SEO pages, that same discipline matters: do not promise hidden capabilities, paid-provider limits, or setup shortcuts unless the current docs say so. Trust compounds when the guide is accurate even in the boring operational edge cases that matter during real maintenance windows.

Operator note

How to Use OpenClaw Reactions works best when it is written into a small runbook instead of treated as a magic switch. Record who owns the workflow, which config keys are allowed, which credentials are required, what the agent may do without approval, and what counts as a failure. OpenClaw gives agents broad tools, but the reliable version is boring: one source of truth, one verification step, and one rollback path when a provider or channel behaves differently than expected.