Summary

When a user sends a top-level message in a Slack channel, OpenClaw creates a channel-level session and the bot replies inside a thread under that message. The reply lives visibly inside a Slack thread, but the OpenClaw session is not promoted to a thread-scoped session.

When the user then replies inside that same thread, OpenClaw does not match it back to the original session. It opens a brand new thread-scoped session and all subsequent messages route there, with no link to the turn that started the conversation.

So the asymmetry is:

• Inbound (top-level message) → channel session, with bot delivery happening in a Slack thread.
• Outbound (bot reply) → session key stays at channel scope, even though the reply created a thread.
• Inbound (user replies in that thread) → session key resolves to a new thread-scoped session, disconnected from the original.

In older OpenClaw versions this worked correctly: either the session stayed at channel scope on both sides, or the session got promoted to thread scope at delivery time so the next inbound thread message landed in the same session.

Environment

• OpenClaw 2026.5.5 (npm latest)
• Channel: Slack (Socket Mode)
• Config:
  • messages.groupChat.visibleReplies = "automatic"
  • channels.slack.replyToMode = "first"
  • channels.slack.replyToModeByChatType = { direct: "off", group: "first", channel: "first" }
  • channels.slack.thread = { historyScope: "thread", inheritParent: false }
• No bindings[] for the affected channel.

Reproduce

1. In a Slack channel where the bot is active, send a top-level message that mentions the bot.
   • OpenClaw opens session: agent:main:slack:channel:<channelId>
   • Bot replies in Slack inside a thread under that message.
   • Session key remains agent:main:slack:channel:<channelId> (no thread suffix).
2. Reply to the bot inside that thread.
   • OpenClaw opens a new session: agent:main:slack:channel:<channelId>:thread:<thread_ts>
   • All further messages in that thread route to this new session.
3. Inspect openclaw status / sessions list.

Actual

Two distinct OpenClaw sessions for what is, from the user's perspective, one continuous conversation:

agent:main:slack:channel:<channelId>                       ← initial turn (visible in Slack as a thread reply)
agent:main:slack:channel:<channelId>:thread:<thread_ts>    ← every subsequent thread message

The bot has no continuity with the message that started the thread.

With messages.groupChat.visibleReplies = "message_tool", additional per-message sessions can also appear inside the same thread.

Expected

When OpenClaw replies inside a Slack thread, the session and the Slack thread should stay in sync, so that subsequent inbound messages in that thread route to the same session as the original turn.

That can mean either:

• the session stays at channel scope on both sides (older default), or
• the session gets promoted to a thread-scoped session at delivery time and the next inbound thread message resolves to that same session.

The current behavior — channel-scoped on the way out, thread-scoped on the way back in — is what causes the discontinuity.

Impact

• The bot has no memory of the message it just replied to as soon as the user replies inside the thread.
• Session list bloat — every Slack thread leaves behind a separate OpenClaw session.
• Channel context is fragmented across many sessions.
• Worse with messages.groupChat.visibleReplies = "message_tool", where individual assistant replies can create their own per-message sessions.