-
-
Notifications
You must be signed in to change notification settings - Fork 69.5k
[Feature]: Mattermost: support Slack-like “auto-thread replies” so each top-level message can become its own session/thread #29058
Description
Summary
Mattermost: support Slack-like “auto-thread replies” so each top-level message can become its own session/thread
Problem to solve
Context / problem
In Slack, it’s easy to get one OpenClaw session per thread because the bot can reply in a thread (and thread replies get a 🧵 session suffix). This makes concurrent conversations in the same channel very usable.
In Mattermost, OpenClaw only treats messages as “threaded” when the incoming post has root_id set (i.e. the user already replied in a thread). That means to get per-thread sessions you currently have to do a tedious two-step: send a top-level message, then send a second message as a thread reply to actually start the bot in a thread/session.
Versions
OpenClaw: 2026.2.26
Mattermost plugin: @openclaw/mattermost (loaded, 2026.2.26)
Mattermost server: (fill in)
Current behavior
In a Mattermost channel, send a top-level post that mentions/triggers the bot.
Bot replies, but the reply is not in a thread (because post.root_id is empty).
The conversation uses the channel session, so multiple “topics” in the same channel get mixed.
If I manually create a thread (reply to the post) and talk to the bot inside that thread, OpenClaw does create a separate session key (works great), but it requires that extra manual step.
Proposed solution
Expected behavior
Provide a way for Mattermost to behave like Slack: when the bot is triggered by a top-level channel message, the bot should be able to:
Reply in a new thread anchored on that message (root = post.id)
Route that interaction to a thread-scoped session key (e.g. …:thread:<post.id>) so each top-level “topic” can become its own isolated session without requiring a second user message.
Proposed config / API (suggestion)
Add a Mattermost setting similar to Slack’s replyToMode, e.g.:
{
channels: {
mattermost: {
replyToMode: "off" | "first" | "all" // default "off" for backwards compatibility
}
}
}
Semantics suggestion:
off (default): current behavior (reply in channel unless already in a thread)
all: for channel/group messages, if post.root_id is empty, reply using root_id = post.id (i.e. start a thread) and use thread session key suffix 🧵<post.id>
Implementation hint (what seems needed)
In the Mattermost monitor/dispatcher, when building thread/session context:
Today it uses threadRootId = post.root_id?.trim() || undefined
For “auto-thread replies”, it likely needs logic like:
if replyToMode === "all" and post.root_id is empty and chat is channel/group:
treat threadRootId = post.id
resolve thread session keys using that
send replies with replyToId/thread root set to post.id
This would remove the “send a second message” workaround and make Mattermost usable for concurrent sessions like Slack.
Why this matters
Without this, per-thread sessions in Mattermost are technically supported but ergonomically painful, and it’s hard to run multiple concurrent topics in one channel without context collisions.
Alternatives considered
No response
Impact
multi agent setup, everyone using matter
no session stability
Evidence/examples
No response
Additional information
No response