Summary

• Problem: In Slack channels with requireMention: true, follow-up replies in a thread do not reach the bot unless the user re-mentions it — unless the bot happened to be the root-message author (parent_user_id === botUserId). The very common pattern of user starts thread → bot joins via @mention → user replies without @mention was silently dropped.
• Root cause: implicitMention only checked message.parent_user_id === ctx.botUserId. This misses threads where a third party started the thread and the bot joined via @mention.
• Fix: Also set implicitMention = true when the bot has a prior thread session (i.e. it has already replied in this thread). Uses the existing synchronous readSessionUpdatedAt helper — no extra Slack API call required. As a bonus, storePath (which was computed twice) is now computed once and shared.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Channels / messaging (Slack)

Linked Issue/PR

• Closes Slack: implicitMention should check thread participation, not just parent_user_id #25760

User-visible / Behavior Changes

When requireMention: true is configured for a Slack channel:

• Before: User starts a thread → bot joins via @mention → user's follow-up reply (no @mention) is silently dropped.
• After: User starts a thread → bot joins via @mention → user's follow-up reply (no @mention) is delivered to the bot because the bot has a prior session for that thread.

Threads where the bot never replied are unaffected — the mention requirement still applies.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No — the fix uses the existing synchronous readSessionUpdatedAt helper (JSON file read), not an API call.
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• Slack Socket Mode
• Config: requireMention: true, thread.inheritParent: true, replyToMode: all

Steps

1. User sends a message in a channel → creates a new thread
2. User @mentions the bot → bot replies (bot now has a thread session)
3. User replies in the thread without @mention
4. Before fix: message dropped. After fix: bot receives the message.

Expected

Bot receives the follow-up reply.

Evidence

• 2 new unit tests added in prepare.test.ts

Human Verification (required)

• Verified scenarios: new unit tests covering the (a) no-prior-session case (still blocked) and (b) existing-session case (now passes through).
• Edge cases checked: DMs are unaffected (isDirectMessage guard). Threads where bot has no session are unaffected.
• What you did not verify: live Slack Socket Mode end-to-end test.

Compatibility / Migration

• Backward compatible? Yes — threads where the bot authored the root message are unchanged.
• Config/env changes? No
• Migration needed? No

Failure Recovery (if this breaks)

• How to disable/revert: revert the botParticipatedInThread addition in src/slack/monitor/message-handler/prepare.ts
• Known bad symptoms: none expected — the check is additive

Risks and Mitigations

• Risk: If a thread session file is stale (e.g. from a previous unrelated session sharing the same key), the bot might receive messages it shouldn't.
  • Mitigation: Session keys are scoped per channel+thread, so key collisions are not realistic.

Greptile Summary

This PR fixes a bug where follow-up thread replies in Slack channels with requireMention: true were dropped when users didn't re-mention the bot. The fix extends implicitMention logic to check if the bot has previously participated in a thread (via session file), not just when the bot authored the root message.

Key changes:

• Moves storePath computation earlier (line 215-219) so it's available for both the new thread participation check and later session operations
• Adds botParticipatedInThread check (line 244-245) using readSessionUpdatedAt to detect existing thread sessions
• Updates implicitMention condition (line 246-250) to include bot thread participation: (message.parent_user_id === ctx.botUserId || botParticipatedInThread)
• Adds two unit tests covering the new behavior: one confirming messages are still blocked without prior participation, another confirming they pass through with prior participation

This is a targeted fix that reuses existing session infrastructure without adding API calls or changing core behavior patterns.

Confidence Score: 5/5

• Safe to merge with minimal risk
• The fix is well-scoped, thoroughly tested with two new unit tests, uses synchronous file read (no new API calls), and maintains backward compatibility. The storePath refactor eliminates redundant computation. The readSessionUpdatedAt helper is already used throughout the codebase for similar purposes.
• No files require special attention

_{Last reviewed commit: ec946d7}