openclaw - 💡(How to fix) Fix Telegram group message recorded into agent session but no run dispatched until next message [1 comments, 2 participants]

Summary

A Telegram group message was accepted into an agent conversation but no agent/model run was dispatched. The next message in the same group triggered a run, and the agent then answered the previous message.

This makes the agent appear silent even though the inbound message was not rejected.

Environment

• OpenClaw version: 2026.5.12
• Channel: Telegram group
• Agent route: group bound to a non-main agent
• Group config:
  • channels.telegram.groups.<group>.requireMention = false
  • messages.visibleReplies = automatic
  • messages.groupChat.visibleReplies = automatic
• Telegram privacy mode is not the issue because the message reached OpenClaw/session context.

What happened

Timeline, group/chat IDs redacted:

1. Agent had just successfully replied in the Telegram group and sent a file using the message tool.
2. User sent a normal follow-up message in the same group: I think we need to evaluate whether factors like 1.2 * 1.2 * 1.1 are reasonable
3. No visible reply was sent, and no assistant/tool call appeared immediately after that user message.
4. Several hours later, user sent ???.
5. The agent immediately answered the earlier follow-up, showing that the earlier message was available in the conversation context.

Observed evidence

The session history later showed the earlier user message followed by the ??? user message, then the assistant response. There was no assistant/tool call between the earlier user message and the later ???.

Relevant local code path appears to allow this class of outcome:

• runPreparedChannelTurnCore records inbound session first.
• If admission is observeOnly, dispatch is suppressed:
  • /app/dist/kernel-5-rDHkvC.js
• Ingress can return non-dispatch admissions such as observe, skip, or drop:
  • /app/dist/runtime-DIN0JAgX.js

However, the transcript/session history did not persist the ingress admission or reasonCode, so it is not possible to determine after the fact whether this specific event was observeOnly, skip, stale state, or another dispatch suppression path.

Expected behavior

For a group with requireMention=false and an allowlisted sender/group, a normal inbound text message should either:

1. Dispatch an agent turn, or
2. Persist an explicit admission/reasonCode explaining why it did not dispatch.

Actual behavior

The message was available to the later turn, but no immediate run/reply happened, and no durable diagnostic reason was available in session history.

Request

Please persist or expose ingress/turn admission diagnostics for channel messages, especially:

• dispatch
• observeOnly
• skip
• drop
• reasonCode / decisive gate
• whether the message was recorded as pending history vs recorded as a session user message
• active/stale run state if dispatch was suppressed

This would make Telegram group "silent agent" cases debuggable without needing live debug logs at the exact time.