Problem

In Slack, OpenClaw currently enforces mention-gating in channels (requireMention: true). The intended “polite” behavior is:

• respond if @mentioned
• respond in DMs
• respond to thread replies when the bot is already part of the thread (human-like: once you’re in a thread, replies are implicitly addressed)

However, the current Slack “implicit mention” logic is too narrow.

Current behavior

For a message in a channel, OpenClaw will skip replies unless it detects an explicit mention, or an implicitMention.

In the current implementation, implicitMention is computed as (approx):

• implicitMention = !isDM && botUserId && message.thread_ts && message.parent_user_id === botUserId

So a thread reply is only treated as implicitly addressed if the parent/root message was authored by the bot.

Why this fails in real usage

A very common/normal Slack flow is:

1. User posts in a channel and @mentions the bot to pull it in
2. Bot replies in that thread
3. User continues the conversation in the same thread without @mentioning

In this flow, parent_user_id is the user (not the bot), so OpenClaw treats step (3) as no-mention and skips.

We observed log entries like:

• {"module":"slack-auto-reply","channel":"C06QAJ35QPL","reason":"no-mention"} skipping channel message

Even though:

• the message is a thread reply (thread_ts present)
• the bot has replied earlier in the thread

Desired behavior

Add support for “thread participant implicit mention”:

• If message.thread_ts is present (thread reply) and the bot has participated in that thread, treat it as implicitly addressed (i.e., bypass mention gating).

Implementation idea:

• On a thread reply, look up thread history with conversations.replies(channel, thread_ts) (or a cached thread-participant map) and check whether any message in the thread has user == botUserId / bot_id matching the app.

Config suggestion

Make it configurable (defaults conservative):

channels: {
  slack: {
    implicitMentionMode: "parent-only" | "thread-participant" // default: parent-only
  }
}

Notes

• This is especially important for private channels (e.g. #showtrail) where users expect threads to behave like a contained conversation.
• Scopes/events required for this approach are already common (groups:history, message.groups, etc.), and can be documented.