Summary

Add a config option to disable the thread participation auto-reply behavior introduced in #29165, so operators can opt out of the bot auto-responding in threads it has previously participated in.

Problem to solve

PR #29165 added always-on thread participation tracking: once the bot replies in a Slack thread, it auto-responds to all subsequent messages in that thread without requiring @mention. This bypasses the existing requireMention gating, with no way to opt out.

Two issues with the current implementation:

1. No opt-out: Operators who set requireMention (explicitly or via the default true) expect mention gating to apply consistently. The thread participation cache silently bypasses this contract — the bot responds to non-mentioned messages in threads where it has previously replied, even though requireMention is true.

2. Non-deterministic behavior from volatile cache: The participation cache is in-memory only (24h TTL, 5000-entry soft cap, no persistence). This means:

   • Process restart clears all participation data → bot stops auto-replying in previously active threads
   • Cache eviction under load → same effect for oldest entries
   • TTL expiry → threads older than 24h lose auto-reply silently

   From the user's perspective: the bot replies without mention for a while, then suddenly stops, then starts again after a new mention. The behavior is correct from the code's perspective but unpredictable from the user's.

Proposed solution

Add a config option under channels.slack.thread:

channels:
  slack:
    thread:
      autoReplyOnParticipation: true  # default: true (preserves current behavior)

When false, the hasSlackThreadParticipation() check in prepareSlackMessage() is skipped, and implicitMention only fires for parent_user_id === botUserId (the pre-#29165 behavior).

This is a minimal, backward-compatible change — one boolean config check wrapping the existing hasSlackThreadParticipation call.

Alternatives considered

• Reverting feat(slack): track thread participation for auto-reply without @mention #29165 entirely: Too aggressive — many users want this behavior. An opt-out is more appropriate.
• Persisting the cache to disk: Addresses the non-determinism but doesn't address the opt-out need. Also adds I/O overhead for a feature not all operators want.
• Using session existence instead of a separate cache: PR feat(slack): follow threads where bot was previously mentioned #30754 explored this approach but was closed when feat(slack): track thread participation for auto-reply without @mention #29165 merged. The session-based approach had scoping issues (baseSessionKey fallback was too broad).

Impact

• Affected: Operators using requireMention (default true) in Slack channels with threaded conversations
• Severity: Medium — bot responds to messages it shouldn't, creating noise in busy channels
• Frequency: Every thread where the bot participates
• Consequence: Unwanted bot responses in threads, undermining the requireMention contract. Non-deterministic behavior after restarts/eviction confuses users.

Evidence/examples

• PR feat(slack): track thread participation for auto-reply without @mention #29165 introduced the behavior (merged 2026-03-01)
• PR feat(slack): follow threads where bot was previously mentioned #30754 proposed a config-toggled alternative (followMentionedThreads) but was closed when feat(slack): track thread participation for auto-reply without @mention #29165 merged. Its closing comment noted: "If there's demand for disabling this behavior per-workspace, that could be a separate small PR."

Additional information

The proposed config key autoReplyOnParticipation aligns with the existing SlackThreadConfig pattern (historyScope, inheritParent, initialHistoryLimit).

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)