Bug Description

isSilentReplyText() in src/auto-reply/tokens.ts matches NO_REPLY at the end of any response text, even when the response contains substantive content. This causes legitimate replies to be silently suppressed.

Current behavior

The regex \bNO_REPLY\b\W*$ matches when NO_REPLY appears at the end of a multi-line response. For example:

Tu as fait un choix de Territoire.
[... 5 lines of substantive reply ...]
Dors.

NO_REPLY

This entire response is treated as a silent reply and never delivered to the user on the channel (WhatsApp, Telegram, etc.), even though it contains meaningful content.

Root cause

The system prompt instructs the agent:

If you use message (action=send) to deliver your user-visible reply, respond with ONLY: NO_REPLY (avoid duplicate replies).

Some models (observed with Gemini 3 Pro) generalize this instruction and append NO_REPLY to direct conversational replies (without having used the message tool), intending it as "no response needed from the human." The regex then matches and kills the entire message.

Expected behavior

isSilentReplyText() should only return true when the entire response text (trimmed) is NO_REPLY, not when it appears at the end of substantive content.

Suggested fix

function isSilentReplyText(text: string, token = SILENT_REPLY_TOKEN): boolean {
    if (!text) return false;
    return text.trim() === token;
}

Or at minimum, require that the text before NO_REPLY is only whitespace:

function isSilentReplyText(text: string, token = SILENT_REPLY_TOKEN): boolean {
    if (!text) return false;
    const escaped = escapeRegExp(token);
    return new RegExp(`^\\s*${escaped}\\s*$`).test(text);
}

Environment

• OpenClaw v2026.2.15
• Agent model: Gemini 3 Pro Preview
• Channel: WhatsApp (direct message)

Workaround

Added explicit instructions in agent workspace (AGENTS.md) telling the model not to use NO_REPLY in direct conversation responses. This is fragile — fixing the regex upstream is the correct solution.