Summary

Slack docs say channel messages are mention-gated by default, but untagged replies inside a bot-participated Slack thread should bypass requireMention unless channels.slack.thread.requireExplicitMention is true. The inbound gating code supports that behavior via implicit mention kinds, but not every visible threaded Slack send records bot participation.

This can make an already-active Slack thread look visibly bot-participated while later untagged user replies are still dropped as no-mention.

Observed behavior

• In a Slack channel thread, the bot had been explicitly mentioned and visibly replied multiple times.
• requireMention: true was configured globally and for the channel.
• Explicit @bot mentions triggered the bot.
• Untagged replies in the already-active thread did not trigger the bot.
• Visible bot replies were often delivered through Slack outbound/message-tool-style paths rather than only the ordinary final reply pipeline.

Expected behavior

When channels.slack.thread.requireExplicitMention is unset or false, a user reply in a thread where the bot has visibly participated should count as an implicit mention and bypass requireMention.

Source investigation

Inbound mention gating appears correct:

• extensions/slack/src/monitor/message-handler/prepare.ts computes implicit mention kinds from:
  • parent_user_id === botUserId
  • hasSlackThreadParticipationWithPersistence(accountId, channelId, threadTs)
• thread.requireExplicitMention disables implicit thread mentions by passing an empty allowed implicit-kind list.
• Otherwise, the mention decision accepts bot-thread participation as an implicit mention.

Participation state exists and persists:

• extensions/slack/src/sent-thread-cache.ts records accountId:channelId:threadTs in memory and persistent keyed state with TTL.

Some outbound paths record participation:

• Normal inbound assistant reply dispatch records after successful visible delivery.
• Slack action runtime records for sendMessage and uploadFile, so generic Slack message(action="send") is likely covered when it goes through that action runtime.

But the shared Slack send primitive does not record participation:

• extensions/slack/src/send.ts sendMessageSlack(...) can successfully post into a thread and return { messageId, channelId }, but does not call recordSlackThreadParticipation(...).

That leaves visible threaded sends through lower-level/direct paths uncovered, including Slack outbound adapter/Block Kit/presentation delivery, attached-result delivery, approval-card/direct Slack sends, and other direct sendMessageSlack(...) callers.

Minimal reproduction shape

1. Configure Slack with requireMention: true and leave channels.slack.thread.requireExplicitMention unset/false.
2. Send a visible bot message into Slack channel thread T through a path that calls sendMessageSlack(..., { threadTs: T }) directly rather than action-runtime recording.
3. Send an untagged user reply in thread T, with parent_user_id not equal to the bot user id.
4. Expected: inbound prepare treats the thread as bot-participated and handles the message.
5. Current risk: participation cache is missing, so prepare drops it as no-mention.

Proposed fix

Record Slack thread participation centrally in sendMessageSlack(...) after successful threaded sends, using the resolved result.channelId and normalized opts.threadTs:

const threadTs = normalizeSlackThreadTsCandidate(opts.threadTs);
if (threadTs && result.channelId && account.accountId) {
  recordSlackThreadParticipation(account.accountId, result.channelId, threadTs);
}

This should make all successful visible threaded Slack sends consistently seed implicit mention state. Existing action-runtime recording may be left in place as harmless duplicate/idempotent recording, or removed once central coverage is tested.

Tests to add

• sendMessageSlack records thread participation after a successful threaded send.
• sendMessageSlack does not record participation when no threadTs is present.
• Slack outbound adapter / deliverOutboundPayloads into a thread records participation.
• Inbound prepare accepts an untagged thread reply after central/outbound participation is recorded when requireMention: true and thread.requireExplicitMention: false.
• Existing tests continue to show thread.requireExplicitMention: true requires an explicit mention.

References

Docs claim:

• docs/channels/slack.md mention sources include implicit reply-to-bot thread behavior.
• channels.slack.thread.requireExplicitMention default is false; bot-participated thread replies bypass requireMention unless it is true.