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)

• Bug fix
• Feature
• Refactor
• 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 [Bug]: Slack extension plugin ignores threadId when reading messages #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

• 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 Summary

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.

Confidence Score: 5/5

• 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}

_{(4/5) You can add custom instructions or style guidelines for the agent here!}