Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Feature]: Slack: Support thread replies (thread_ts) in sendMessage [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#68585•Fetched 2026-04-19 15:09:54
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
kurasawa0922kurasawa0922
Participants
kurasawa0922kurasawa0922
Timeline (top)
labeled ×1

When a user replies to a bot message in a Slack thread, OpenClaw's response is posted to the channel root instead of the thread. The Slack chat.postMessage API supports thread_ts parameter for thread replies, but OpenClaw's Slack plugin does not pass this parameter.

Root Cause

All Slack users who reply to bot messages in threads. Severity: medium (breaks expected UX). Frequency: every time a user replies in a thread. Impact: conversations become fragmented because bot replies appear in the channel root instead of the thread.

RAW_BUFFERClick to expand / collapse

Summary

When a user replies to a bot message in a Slack thread, OpenClaw's response is posted to the channel root instead of the thread. The Slack chat.postMessage API supports thread_ts parameter for thread replies, but OpenClaw's Slack plugin does not pass this parameter.

Problem to solve

When OpenClaw receives a message in a Slack thread (i.e., the incoming event has a thread_ts field), the reply should be posted back into the same thread by passing thread_ts to chat.postMessage. This matches how native Slack bots work and is expected behavior by users. The existing replyToMode config partially addresses this but thread replies from users are not being routed back to the thread.

Proposed solution

In the Slack plugin's sendMessage implementation, check if the inbound event contains a thread_ts field. If present, include it in the chat.postMessage API call so the reply is posted into the same thread. This could also be controlled via the existing replyToMode config (channels.slack.replyToMode: "all") but the current behavior does not work for user-initiated thread replies.

Alternatives considered

No response

Impact

All Slack users who reply to bot messages in threads. Severity: medium (breaks expected UX). Frequency: every time a user replies in a thread. Impact: conversations become fragmented because bot replies appear in the channel root instead of the thread.

Evidence/examples

The Slack API chat.postMessage supports thread_ts parameter. When a message event has thread_ts in the payload, passing it to chat.postMessage causes the reply to appear in the thread. The existing replyToMode config exists but does not handle user-initiated thread replies correctly. OpenClaw version: 2026.4.15

Additional information

No response

extent analysis

TL;DR

Modify the Slack plugin's sendMessage implementation to include the thread_ts parameter in the chat.postMessage API call when the inbound event contains a thread_ts field.

Guidance

  • Check the inbound event for the presence of a thread_ts field and include it in the chat.postMessage API call if present.
  • Review the existing replyToMode config to determine if it can be leveraged to control this behavior, potentially by setting channels.slack.replyToMode to "all".
  • Verify that the modified implementation correctly posts replies to the same thread by testing with user-initiated thread replies.
  • Consider adding logging or debugging statements to ensure the thread_ts field is being correctly extracted from the inbound event and passed to the chat.postMessage API.

Example

if (inboundEvent.thread_ts) {
  const params = {
    channel: inboundEvent.channel,
    text: replyText,
    thread_ts: inboundEvent.thread_ts
  };
  // Call chat.postMessage with the updated params
  slack.chat.postMessage(params);
}

Notes

The proposed solution assumes that the thread_ts field is correctly extracted from the inbound event and that the chat.postMessage API is called with the updated parameters. Additional testing and verification may be necessary to ensure the modified implementation works as expected.

Recommendation

Apply workaround: Modify the Slack plugin's sendMessage implementation to include the thread_ts parameter in the chat.postMessage API call. This should correctly post replies to the same thread and improve the user experience.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#latency issue#model loading#dependency error#configuration error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix [Feature]: Slack: Support thread replies (thread_ts) in sendMessage [1 participants]