Summary

When OpenClaw is used from a Telegram direct conversation, a fallback message Nothing further to report. can still be posted to Telegram after the assistant has already sent the intended reply through the messaging tool.

This appears to happen when the assistant calls message.send successfully, then the normal assistant final response is empty or otherwise treated as empty by the runtime. The runtime inserts the fallback text and routes it back to the Telegram conversation, creating an extra unwanted message.

Reproduction Context

• Surface: Telegram direct chat
• Tool path: message.send sends the visible reply successfully
• After the tool call, the assistant final response is empty or intentionally omitted because the Telegram message was already sent
• OpenClaw posts an additional fallback message: Nothing further to report.

Expected Behavior

If the assistant has already sent a message through message.send, OpenClaw should not post a generic fallback final message to the same Telegram thread.

Possible acceptable behavior:

• suppress empty final responses for Telegram direct sessions after a successful message.send, or
• keep the fallback internal-only, or
• allow agents/config to disable this fallback per surface/session.

Actual Behavior

Telegram receives the intended message, then also receives:

Nothing further to report.

This persists even after adding local agent instructions telling the assistant not to use that phrase, which suggests the text is injected by OpenClaw runtime rather than generated by the agent prompt.

Impact

• Creates confusing duplicate replies in Telegram
• Makes the assistant look like it is ignoring its own instructions
• Breaks chat UX for direct messaging surfaces where message.send is the actual user-visible response

Notes

This was observed repeatedly in a direct Telegram chat after successful message.send calls. Adding a non-empty internal final message appears to be a workaround, but it is fragile and easy for agents to miss.