Summary

• Problem: when Slack channels require mentions, once the bot replies in a thread, later thread replies can continue triggering the bot without an explicit mention.
• Why it matters: this bypasses strict mention gating for users who expect every Slack thread reply to explicitly mention the bot.
• What changed: added a Slack thread config toggle, autoReplyOnParticipation, to control whether thread participation should continue to count as an implicit mention.
• What did NOT change (scope boundary): this does not change other channels' implicit mention behavior, and it does not change Slack's default behavior unless the new config is explicitly set to false.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Feature]: Add opt-out config for thread participation auto-reply (#29165) #31728
• Related #
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: Slack inbound handling treated prior bot participation in a thread as an implicit mention, which allowed later thread replies to bypass requireMention.
• Missing detection / guardrail: there was no Slack-specific configuration to disable participation-based implicit mentions while preserving backward compatibility.
• Prior context (git blame, prior PR, issue, or refactor if known): reported in [Feature]: Add opt-out config for thread participation auto-reply (#29165) #31728.
• Why this regressed now: N/A
• If unknown, what was ruled out: N/A

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/slack/src/monitor.tool-result.test.ts
• Scenario the test should lock in: Slack thread replies still count as implicit mentions by default, but stop doing so when channels.slack.thread.autoReplyOnParticipation is explicitly set to false.
• Why this is the smallest reliable guardrail: the behavior is decided in Slack monitor mention-gating prep logic, and this test file already exercises that path directly.
• Existing test that already covers this (if any): the existing implicit mention test in the same file was updated to cover the default path.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• Added channels.slack.thread.autoReplyOnParticipation
• Default remains true, so existing Slack behavior is preserved
• When explicitly set to false, each Slack thread reply must explicitly mention the bot to trigger a response

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local dev environment
• Model/provider: N/A
• Integration/channel (if any): Slack
• Relevant config (redacted): channels.slack.channels.C1.requireMention=true

Steps

1. Configure a Slack channel with requireMention: true.
2. Send a channel message that explicitly mentions the bot and let the bot reply in a thread.
3. Send another message in the same thread without explicitly mentioning the bot.
4. Repeat with channels.slack.thread.autoReplyOnParticipation: false.

Expected

• Default config: existing behavior remains unchanged.
• With autoReplyOnParticipation: false: non-mentioned thread replies should not trigger the bot.

Actual

• Before this change, participation-based implicit mentions were always enabled.
• After this change, they are configurable and can be disabled explicitly.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: ran the updated Slack monitor tests locally and manually verified the behavior with a real OpenClaw instance connected to a Slack bot
• Edge cases checked: default behavior still allows participation-based implicit mentions, and setting channels.slack.thread.autoReplyOnParticipation=false requires an explicit mention for later thread replies
• What you did not verify: broader Slack workspace scenarios outside the thread mention-gating flow

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (Yes)
• Migration needed? (No)
• If yes, exact upgrade steps:

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: remove the new config and fall back to default behavior, or revert this PR
• Files/config to restore: channels.slack.thread.autoReplyOnParticipation
• Known bad symptoms reviewers should watch for: Slack thread replies unexpectedly stop or continue auto-triggering despite config

Risks and Mitigations

• Risk: participation-based implicit mention behavior could accidentally change for existing users
  • Mitigation: the default remains true, and tests cover both the default path and the explicit opt-out path

Made with Cursor