Bug: message_tool_only group chats can still go silent when the model emits a final reply instead of using message

Summary

In OpenClaw 2026.5.20 (e510042), group/channel chats configured with:

{
  "messages": {
    "groupChat": {
      "visibleReplies": "message_tool"
    }
  }
}

can still silently fail to reply in the room when the agent produces a normal final assistant response but forgets to call the message tool.

This is distinct from the previous issue fixed by #75099. That PR adds fallback behavior when the message tool is unavailable. In this case the message tool is available, but the model does not use it, so the normal final reply remains private and the group sees no response.

Environment

• OpenClaw: 2026.5.20 (e510042)
• OS: macOS
• Channel: Feishu group chat
• Config: messages.groupChat.visibleReplies = "message_tool"
• Affected agent: Feishu-backed sub-agent in a group chat

Observed behavior

For several Feishu group turns:

1. Inbound group mention is received and dispatched.
2. The agent processes successfully and emits a final assistant text.
3. sourceReplyDeliveryMode is message_tool_only.
4. didSendViaMessagingTool = false.
5. messagingToolSentTexts = [].
6. OpenClaw suppresses automatic source delivery because of message_tool_only.
7. The final assistant text is visible only in internal/session traces; the Feishu group receives nothing.

When the same task is retried and the agent calls message(action="send", ...), the group-visible reply works.

Root cause

message_tool_only currently treats normal final replies as private whenever the message tool is available. That is correct as the primary contract, but there is no last-mile runtime guard for the common failure mode where the model produces a final answer and forgets the tool call.

The relevant runtime path suppresses final delivery unconditionally:

if (run.sourceReplyDeliveryMode === "message_tool_only") {
  logVerbose("followup queue: automatic source delivery suppressed by sourceReplyDeliveryMode: message_tool_only");
  return;
}

There is a similar suppression path in the normal reply dispatch path unless the payload is explicitly marked to deliver despite source reply suppression.

Expected behavior

When all of the following are true:

• source reply delivery mode is message_tool_only
• chat type is group or channel
• inbound event is not a room/system event
• no successful messaging-tool delivery evidence exists
• the final payload contains sendable user-facing text or media

OpenClaw should either:

1. deliver that final payload once as a fallback, or
2. emit a visible deterministic warning telling the operator/user that the agent failed to use message

Option 1 is preferable because it preserves user-visible responsiveness while keeping normal message tool delivery as the primary path.

Local hotfix tested

I tested a local dist-layer hotfix that adds a guard equivalent to:

function shouldDeliverMessageToolOnlyFinalReplyFallback(params) {
  if (params.sourceReplyDeliveryMode !== "message_tool_only") return false;
  if (params.successfulSideEffectDelivery) return false;
  const chatType = normalizeLowercaseStringOrEmpty(params.chatType);
  if (chatType !== "group" && chatType !== "channel") return false;
  if (params.inboundEventKind === "room_event") return false;
  return params.payloads.some((payload) =>
    !payload.isReasoning && hasOutboundReplyContent(payload, { trimText: true })
  );
}

Then:

• in the queued follow-up path, do not return early for message_tool_only if the fallback predicate is true
• in the normal reply path, mark final payloads with markReplyPayloadForSourceSuppressionDelivery(...) when the fallback predicate is true
• still suppress if there is any existing message/media/target delivery evidence, preventing duplicate replies

Verification performed locally:

• node --check dist/agent-runner.runtime-*.js
• openclaw config validate
• openclaw gateway restart
• openclaw gateway call health --json

Why this should be upstreamed

Prompt-only mitigation is not reliable. Even with strong system/SOUL instructions, models sometimes answer in the final channel instead of calling message. In group/channel chat, that creates a false success state: OpenClaw has a completed run and internal text, but the user sees silence.

This fallback keeps the intentional group safety posture:

• message tool remains the preferred visible delivery path
• no duplicate send when the tool already sent content
• no fallback for room/system events
• no change for direct messages

But it removes the most damaging failure mode: a successful run with no visible group response.

Related

• #74876
• #75099