#22216: fix(slack): enable thread reply reading in slack extension plugin

## Summary - **Problem:** `message read` with `threadId` returns channel-level messages instead of thread replies when the Slack extension plugin is active - **Why it matters:** Thread reply reading is completely broken — agents cannot read Slack thread context - **What changed:** Added `includeReadThreadId: true` to the extension's `handleSlackMessageAction` call in `extensions/slack/src/channel.ts` - **What did NOT change (scope boundary):** No changes to the built-in Slack adapter, message tool schema, or any other extension ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [x] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #22219 ## User-visible / Behavior Changes `message read` with `threadId` now correctly returns thread replies (via `conversations.replies`) instead of channel-level messages when the Slack extension plugin is active. ## Security Impact (required) - New permissions/capabilities? `No` - Secrets/tokens handling changed? `No` - New/changed network calls? `No` (already calls `conversations.replies` when `threadId` is present — this just enables the code path) - Command/tool execution surface changed? `No` - Data access scope changed? `No` ## Repro + Verification ### Environment - OS: Ubuntu 6.8.0-100-generic (arm64) via UTM VM - Runtime/container: Node v22.22.0, pnpm dev (local source build) - Model/provider: Anthropic Claude Opus 4 - Integration/channel: Slack extension plugin - Relevant config: Slack extension active (overrides built-in adapter at runtime) ### Steps 1. Have the Slack extension plugin active 2. Call `message` tool with `action: "read"`, `channelId: "C0ACPS2J7GV"`, `threadId: "1771622303.670079"`, `limit: 5` 3. Before fix: returns 5 channel-level messages (joins, top-level posts) 4. After fix: returns 5 thread replies from the specified thread ### Expected Thread replies from the specified thread (via Slack `conversations.replies` API) ### Actual Before fix: channel-level messages returned (`conversations.history` called instead of `conversations.replies`), `threadId` silently ignored. After fix: correct thread replies returned ✅ ## Evidence - [x] Trace/log snippets Before fix (debug logging added to trace the issue): ``` [DEBUG runMessageAction] action=read params.threadId=1771622303.670079 channel=slack [DEBUG slack-message-actions read] includeReadThreadId=false threadId=1771622303.670079 [DEBUG readSlackMessages] channelId=C0ACPS2J7GV threadId=NONE ``` Key line: `includeReadThreadId=false` — the flag was not set by the extension, so `threadId` was dropped before reaching `readSlackMessages`. After fix: `conversations.replies` called correctly, all 23 thread replies returned with correct `thread_ts` and `parent_user_id` fields. ## Human Verification (required) - **Verified scenarios:** Read thread replies from a real Slack channel thread (#developer-content-team) with 23 replies — all returned correctly after fix. Also verified channel-level reads (without threadId) still work as before. - **Edge cases checked:** Thread with mixed bot and human replies; thread parent message correctly excluded from replies (existing filter in `readSlackMessages`). - **What you did not verify:** Other Slack extensions, multi-account setups, paginated thread reads (>1000 replies). ## Compatibility / Migration - Backward compatible? `Yes` - Config/env changes? `No` - Migration needed? `No` ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: Remove the single `includeReadThreadId: true` line from `extensions/slack/src/channel.ts` - Files/config to restore: `extensions/slack/src/channel.ts` - Known bad symptoms reviewers should watch for: Thread reads returning empty results or API errors from `conversations.replies` ## Risks and Mitigations `None` — this is a one-line flag addition that aligns the extension with the built-in adapter's existing behavior. The `conversations.replies` code path is already well-tested and used by the built-in adapter. <!-- greptile_comment --> <h3>Greptile Summary</h3> Fixed a bug where reading Slack thread messages returned channel-level messages instead of thread replies. The extension's `handleAction` was missing `includeReadThreadId: true`, which the built-in adapter already had. This flag controls whether `threadId` is passed through to the `readMessages` action. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - Single-line fix adding a missing boolean flag that aligns extension behavior with the built-in adapter. The flag is properly implemented in handleSlackMessageAction (lines 110-112 of slack-message-actions.ts) and simply enables threadId parameter parsing for read actions. No breaking changes or side effects. - No files require special attention _{Last reviewed commit: 11a8f56} <!-- greptile_other_comments_section --> _{(4/5) You can add custom instructions or style guidelines for the agent <a href="https://app.greptile.com/review/github">here</a>!} <!-- /greptile_comment -->