openclaw - 💡(How to fix) Fix [Bug] 2026.4.27: Telegram-inbound-triggered agent replies silently dropped when output contains [[reply_to_current]] directive (groups affected) [1 comments, 2 participants]

Summary

On openclaw 2026.4.27, agent replies triggered by an inbound Telegram message in a group are silently dropped if the agent's output begins with the [[reply_to_current]] directive. The same agent, same chat, same session, when invoked via openclaw agent --deliver, delivers successfully because the CLI-triggered run does NOT add the [[reply_to_current]] prefix to its output.

Repro

1. macOS 15, Apple Silicon, Node 25.8.0, openclaw 2026.4.27 (cbc2ba0) installed via global npm.
2. Configure a bot with at least two groups bound to two different agents (any agent works).
3. From a user in the group, send a plain text message that triggers the agent (e.g. ping).
4. Observe: a session is created/updated under ~/.openclaw/agents/<agent>/sessions/<id>-topic-<n>.jsonl. Trajectory shows prompt.submitted "ping" → model.completed (aborted=False) → trace.artifacts (finalStatus=success) → session.ended. The finalAssistantText / finalAssistantVisibleText contains [[reply_to_current]] pong 🦞 (or similar). NO gateway/channels/telegram sendMessage ok log line follows.
5. Now from the host, run openclaw agent --agent <same agent> --reply-channel telegram --reply-to "<group_id>" --deliver -m "ping". The same agent emits pong 🦞 (no [[reply_to_current]] prefix) and the message IS delivered to the group.

Evidence I gathered today

• lsof -p <gateway_pid> -i shows ESTABLISHED TCP to api.telegram.org — bot is polling normally.
• ~/.openclaw/agents/<agent>/sessions/*.jsonl mtimes update on every inbound — dispatch works.
• Trajectory grep: "text":"[[reply_to_current]] pong 🦞" present for inbound-triggered runs.
• Trajectory grep: "text":"pong 🦞" (no directive) for openclaw agent --deliver CLI runs.
• Today's full sendMessage ok count (chats):
  • 1763781240 (DM): 32 sends — all paths to DM work.
  • -1003787553276 (group): 5 sends — early in the day, before this began.
  • All other groups: 0. Roughly 17 different groups configured.
• Verified the broken delivery is NOT a permission, token, polling, or topic-binding issue (each ruled out individually with lsof, getMe-equivalents via the gateway probe, session/trajectory inspection).

Root cause hypothesis

dist/extensions/telegram/chat-CCwcu7PW.js and dist/monitor-processing-zPNu80js.js parse [[reply_to_current]] and try to resolve a reply_to_message_id from the triggering message. For groups (or specifically forum/topic-aware sends), this resolution appears to fail silently — neither the sendMessage call nor an error is logged, and the message is dropped. The agent then proceeds as if delivery succeeded (finalStatus=success).

Why my earlier issue #75263 was wrong

I closed that one earlier today. The actual bug is upstream of where I claimed it was: not in startup polling, but in the directive-stripping/reply-resolution path.

Suggested investigation

1. In the inbound dispatch path that consumes [[reply_to_current]], log every branch that decides NOT to call sendMessage. Today there is no log line at INFO that distinguishes "send was attempted and failed" from "send was never attempted because directive resolution returned null".
2. Add a fallback: if [[reply_to_current]] cannot be resolved to a reply_to_message_id for the current message, strip the directive and send as a plain message anyway, so the user is not left in silence.
3. Verify the directive-resolution against forum/topic groups specifically — message_thread_id propagation through the dispatch context may be the breakpoint.

Workaround (host-side)

• Until this is fixed, agent replies can be triggered manually via openclaw agent --agent <id> --reply-channel telegram --reply-to "<chat_id>" --deliver -m "<prompt>". This bypasses the directive path.
• Alternatively, configure agents to NOT emit reply directives (no obvious config knob found; would require system-prompt override).

Happy to attach the relevant trajectory excerpts and a redacted log slice if useful.