Summary

message read with threadId returns channel-level messages instead of thread replies when the Slack extension plugin is active.

Steps to reproduce

1. Have the Slack extension plugin active (it overrides the built-in Slack adapter at runtime)
2. Call message tool with action: "read", channelId: "<channel>", threadId: "<thread_ts>", limit: 5
3. Observe that channel-level messages are returned (from conversations.history) instead of thread replies (from conversations.replies)

Expected behavior

Thread replies should be returned when threadId is provided, using the Slack conversations.replies API.

Actual behavior

Channel-level messages are returned. The threadId parameter is silently ignored because includeReadThreadId defaults to false in handleSlackMessageAction, and the extension does not set it to true.

Debug logging confirmed: threadId arrives in runMessageAction params but is dropped before reaching readSlackMessages.

OpenClaw version

2026.2.20

Operating system

Ubuntu (arm64) via UTM VM

Install method

pnpm dev (local source)

Logs, screenshots, and evidence

[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

The middle line shows the bug: includeReadThreadId=false despite threadId being present in params.

Impact and severity

Affected: All users with the Slack extension plugin who attempt to read thread replies via the message tool
Severity: High (thread reading is completely broken)
Frequency: 100% repro
Consequence: Agents cannot read Slack thread replies, only channel-level messages. Thread context is inaccessible.

Additional information

The built-in Slack adapter (channels/plugins/slack.actions.ts) correctly sets includeReadThreadId: true, but the extension (extensions/slack/src/channel.ts) overrides it at runtime without this flag. One-line fix in PR #22216.