openclaw - 💡(How to fix) Fix [Bug]: Slack channel visibleReplies automatic is bypassed for room_event while typing/status still appears

Summary

Slack channel/group turns can ignore messages.groupChat.visibleReplies: "automatic" because non-internal room_event inbound messages are hard-forced to sourceReplyDeliveryMode: "message_tool_only". In the same path, Slack can still show is typing... / typing reaction even though automatic source delivery is suppressed, which makes the UX look like the assistant is going to reply but the final text is invisible unless the model explicitly uses the message tool.

This looks like the same policy family as #84022 (Discord room events forced into message-tool-only), but this report is specifically for Slack and the typing/status mismatch.

Environment

• OpenClaw package: 2026.5.28
• Runtime: macOS Darwin 25.5.0 arm64, Node v24.15.0
• Channel: Slack channel / group chat
• Relevant config:

{
  "messages": {
    "groupChat": {
      "visibleReplies": "automatic"
    }
  }
}

Evidence from installed package

dist/source-reply-delivery-mode-DlaGp-jb.js hard-forces non-internal room events before reading the configured group/channel visible reply mode:

function resolveSourceReplyDeliveryMode(params) {
  if (params.strictMessageToolOnly === true) return "message_tool_only";
  if (params.ctx.InboundEventKind === "room_event" && !isInternalRoomEvent(params.ctx)) return "message_tool_only";
  if (params.requested && (params.requested !== "message_tool_only" || params.messageToolAvailable !== false)) return params.requested;
  // ... later:
  if (chatType === "group" || chatType === "channel") mode =
    (params.cfg.messages?.groupChat?.visibleReplies ?? params.cfg.messages?.visibleReplies) === "message_tool"
      ? "message_tool_only"
      : "automatic";
}

In the Slack pipeline, the effective source-reply mode is resolved, but typing/status callbacks are still supplied unconditionally to the channel reply pipeline:

const sourceReplyDeliveryMode = resolveChannelMessageSourceReplyDeliveryMode({
  cfg,
  ctx: prepared.ctxPayload
});
const sourceRepliesAreToolOnly = sourceReplyDeliveryMode === "message_tool_only";
// ...
typing: {
  start: async () => {
    didSetStatus = true;
    await ctx.setSlackThreadStatus({
      channelId: message.channel,
      threadTs: statusThreadTs,
      status: "is typing..."
    });
    if (typingReaction && message.ts) await reactSlackMessage(...)
  },
  stop: async () => { /* clears status/reaction */ }
}

Observed behavior

1. Slack channel/group message is received and processed.
2. Config asks for automatic visible replies in group/channel chats.
3. Runtime resolves the turn as message_tool_only because it is a non-internal room_event.
4. Normal final assistant text can be transcript-only / not posted back to Slack unless the model calls the message tool.
5. Slack may still show is typing... / typing reaction during the run, making the suppressed final reply look like a dropped reply.

Expected behavior

If messages.groupChat.visibleReplies: "automatic" is supported for Slack channel/group chats, non-internal Slack room events should not be hard-forced into message_tool_only before the config is applied.

If the intended safety contract is that all non-internal room_event turns must be message_tool_only, then:

• the config/docs/schema should make that clear instead of accepting automatic silently; and
• Slack typing/status should be suppressed or aligned with the final delivery policy when automatic source delivery is suppressed, so users are not shown a typing indicator for a reply that will not be posted automatically.

Impact

• Slack users see typing/status but no final assistant reply.
• The configured visibleReplies: "automatic" behavior is surprising/ineffective for Slack channel/group room events.
• Agents must explicitly use message tool delivery to make replies visible, and that path has its own Slack durability issue tracked in #84078.

Related issues

• #84022 — similar room_event hard-force causing Discord final replies to be transcript-only.
• #84078 — Slack message_tool_only source replies can fail because durable send requires reconcileUnknownSend.
• #80715 — related family of Slack replies composed but not posted.