OpenClaw Telegram events and operations

Beyond messages, three operational things happen on a Telegram channel: people react, Telegram itself changes a group's ID, and something fails. OpenClaw has a setting for each: reaction notifications with their levels, config writes triggered by events and commands, and an error reply policy that decides what the chat gets to see.

Reaction notifications

• Telegram reactions arrive as message-reaction updates separate from message payloads, and when enabled OpenClaw enqueues system events that name the emoji, the person and the message it landed on.
• The notification setting takes off, own or all with own as the default, meaning user reactions to bot-sent messages only, best-effort through a sent-message cache, and the reaction level takes off, ack, minimal or extensive with minimal as the default.
• Reaction events still respect the Telegram access controls, the DM policy, the allowlist, the group policy and the group sender list, so unauthorised senders are dropped, and the message-reaction update type is included in the allowed updates for polling and webhooks automatically.
• Telegram provides no topic metadata in reaction updates: ordinary non-forum groups stay chat-scoped, while reactions in forum topics and channel direct messages recover the originating topic from OpenClaw's bounded message cache keyed by account, chat and message ID, so topic config, topic agents and conversation bindings still apply, and when the cached topic is missing or belongs to the wrong scope OpenClaw skips the notification and logs a warning rather than falling back to General or the base chat.

Telegram does not provide topic metadata in reaction updates.

Config writes

Channel config writes are enabled by default whenever the config-writes key is not set to false. On Telegram the writes triggered by events and commands are group migration events, where a migrate-to-chat-ID update rewrites the group entry under the groups map, and the config set and unset commands, which additionally require command enablement. Setting the config-writes key to false under the Telegram block disables them all.

Error reply controls

• When the agent hits a delivery or provider error, the error policy decides whether error messages reach the chat: always sends every error message, once sends each unique error message once per built-in cooldown window, and silent never sends error messages to the chat, with always as the default.
• The policy can be overridden per account, per group and per topic with the same inheritance as the other Telegram config keys, so a noisy group can be set to silent while the channel default stays at always.
• The docs' example keeps always at the channel level and sets one group's entry to silent, suppressing error messages in that group alone.

OpenClaw on Telegram is the channel post these operations belong to, and OpenClaw reactions the cross-channel reaction semantics the notifications feed.

Skipping rather than guessing

The topic-recovery rule is a small example of a consistent choice: when OpenClaw cannot tell which topic a reaction belongs to, it drops the event and says so instead of routing it to the wrong agent. OpenClaw Slack events and operations shows the much larger event surface on Slack, and OpenClaw audit history the history where config writes and their triggers are recorded.

On Diali

Telegram is one of the channels Diali connects from the dashboard, with the runtime config generated and replaced at each release, so the reaction, config-write and error settings here describe how a hosted agent behaves rather than a file you maintain. Telegram on Diali is the channel on Diali and Diali security the boundary every connected channel shares.

• Reactions are their own updates; own is the default scope.
• A reaction with no recoverable topic is skipped, not guessed.
• Errors go to the chat always by default; once and silent are per group too.