openclaw - 💡(How to fix) Fix [Bug]: visibleReplies automatic exposes tool/progress chatter in group rooms [1 comments, 1 participants]

Summary

messages.groupChat.visibleReplies: "automatic" is documented/implemented as the legacy behavior for group/channel room replies, but it currently exposes tool/progress/thinking-style runtime messages in Slack group/channel sessions. Legacy auto-posting behavior showed normal user-facing assistant output in the room, but did not show routine tool call summaries, tool updates, or thinking/progress chatter.

Why this matters

For group/channel rooms, operators currently have two bad choices:

1. visibleReplies: "message_tool" — clean UX, but normal assistant final/conversational replies stay private unless the agent explicitly calls message(action=send).
2. visibleReplies: "automatic" — normal replies are visible, but Slack channels can also receive noisy internal/runtime output such as Working..., tool: exec, command summaries, or similar tool/progress events.

The desired legacy-compatible behavior is: user-facing assistant output is visible automatically, while routine thinking/tool/progress streams remain hidden from the room.

Expected behavior

With messages.groupChat.visibleReplies: "automatic" in a Slack channel/group:

• user-facing assistant conversational output is delivered visibly to the source room
• reasoning/thinking streams are not delivered visibly
• routine tool call summaries are not delivered visibly
• routine tool call updates/progress/status are not delivered visibly
• existing actionable exceptions should continue to work where intended, e.g. approval prompts, generated media/tool media, native command UX, or other payloads that require user action/visibility
• DMs and native command flows should preserve their existing behavior

Actual behavior

After enabling messages.groupChat.visibleReplies: "automatic", Slack group/channel sessions can show runtime/tool/progress chatter in the room alongside normal replies. This does not match the old/legacy automatic room reply behavior.

Likely cause / implementation direction

Recent source-reply delivery changes introduced a binary source delivery mode:

• message_tool_only for default group/channel rooms
• automatic for legacy room replies

The automatic path appears to unsuppress more than just user-facing assistant output. The fix should split source reply visibility from internal/progress event visibility.

Possible implementation shape:

• keep visibleReplies: "automatic" as the legacy room reply mode
• for non-direct Slack/group/channel source turns, only auto-route user-facing assistant output (final and conversational block payloads)
• continue suppressing ACP/tool/thinking/status categories such as:
  • agent_thought_chunk
  • tool_call
  • tool_call_update
  • routine status/progress events
• preserve explicit/actionable payload cases, such as approval prompts and tool media, where current tests intentionally allow delivery

Candidate areas to inspect:

• src/auto-reply/reply/source-reply-delivery-mode.ts
• src/auto-reply/reply/dispatch-from-config.ts
• src/auto-reply/reply/dispatch-acp.ts
• src/auto-reply/reply/acp-projector.ts
• ACP delivery/projector tests around visibleReplies: "automatic"

Related context

PR #73046 (fix(messages): keep group replies tool-only by default) introduced/solidified the current message_tool vs automatic behavior. The issue is not that message_tool exists; that default is useful. The regression is that automatic, described as legacy auto-posting, appears broader than legacy behavior and can surface routine tool/progress output.

Suggested tests

Add/adjust tests for Slack/group/channel source turns with visibleReplies: "automatic":

• final assistant reply is delivered
• conversational block assistant output is delivered if applicable
• routine tool summary is not delivered
• tool call/update ACP events are not delivered
• thinking/reasoning chunks are not delivered
• routine status/progress messages are not delivered
• approval payloads and media/tool attachments that require visibility remain delivered
• visibleReplies: "message_tool" behavior remains unchanged
• native command reply visibility remains unchanged