fix: make replyToMode 'off' actually prevent threading in Slack by unboxed-ai · Pull Request #22944 · openclaw/openclaw

unboxed-ai · 2026-02-21T21:13:13Z

Summary

Three fixes that make replyToMode: "off" work correctly for Slack.

Changes

src/slack/threading.ts — Remove messageTs fallback on statusThreadTs. When no thread exists, the status thread timestamp should not fall back to the message timestamp, which creates a new thread. (Fixes Slack DM threading ignores replyToMode: off — statusThreadTs fallback creates threads #16868)
src/channels/dock.ts — Set allowExplicitReplyTagsWhenOff: false for Slack. System prompt [[reply_to_current]] tags were bypassing replyToMode: "off", creating threads. This is intentionally different from Telegram — see docs update below. (Fixes Slack plugin: [[reply_to_current]] tags bypass replyToMode=off #16080)
src/slack/monitor/provider.ts — Default replyToMode from "all" to "off". The provider had "all" while accounts.ts had "off", contradicting documentation which states "off" is the default. (Fixes Slack: reply threading defaults/overrides are inconsistent (docs say off, monitor defaults all) #20827)
docs/channels/slack.md — Updated to note that Slack strips explicit reply tags in "off" mode and why this differs from Telegram (Slack threads hide messages from channels; Telegram replies remain in the main chat flow).

Migration Note

Existing installs that relied on the implicit "all" default (replies always auto-threaded) should add channels.slack.replyToMode: "all" to their config to maintain previous behavior. This aligns the runtime default with the documented default ("off").

Testing

All 966 test files pass
3 test files updated to match new behavior
Verified on production deployment

Code Review Discussion

The following findings were raised during automated code review (Codex CLI) and reviewed by humans:

Finding 1 (Medium): Default behavior change for unconfigured installs.
The provider.ts change from "all" to "off" is a user-visible behavioral change. Existing installs that never set replyToMode will stop auto-threading.

Decision: Intentional. The docs already document "off" as the default. The "all" fallback contradicted both docs and accounts.ts. Migration path is simple: add replyToMode: "all" to config.

Finding 2 (Low): Status thread target lost for replyToMode: "first".
statusThreadTs now equals replyThreadTs, which is undefined for "first" mode before the first reply.

Decision: Not a real issue. The thread does not exist yet before the first reply — the old messageTs fallback was a no-op on a non-existent thread.

Finding 3 (Low): Docs conflict — explicit reply tags stripped in "off" mode.
allowExplicitReplyTagsWhenOff: false conflicts with docs saying explicit tags are honored.

Decision: Updated docs. Slack threads hide messages from channels, so "off" should mean truly off. Telegram correctly keeps tags honored in "off" mode because replies stay visible in the main chat. The docs update explains this distinction.

Greptile Summary

This PR fixes three bugs that prevented replyToMode: "off" from actually disabling threading in Slack:

threading.ts - removed messageTs fallback for statusThreadTs, preventing unwanted thread creation when replyToMode is "off"
dock.ts - set allowExplicitReplyTagsWhenOff: false for Slack to strip [[reply_to_*]] tags in "off" mode (different from Telegram which keeps them)
provider.ts - changed default replyToMode from "all" to "off" to align with documented default and accounts.ts

The changes are well-tested with 3 test files updated to match the new behavior. The distinction between Slack (threads hide messages) and Telegram (replies stay visible) is clearly documented.

Minor issue: The extension file at extensions/slack/src/channel.ts:180 still has allowExplicitReplyTagsWhenOff: true, though it's not actively used since the core implementation takes precedence. Updating it would keep the codebase consistent.

Confidence Score: 5/5

This PR is safe to merge with minimal risk
The changes are well-reasoned, thoroughly tested (all 966 tests pass, 3 test files updated), and fix documented bugs. The logic is sound: statusThreadTs is now properly tied to replyThreadTs, and the setSlackThreadStatus function already handles undefined values gracefully. The default change aligns with existing documentation. The only minor issue is a cosmetic inconsistency in the extension file that doesn't affect runtime behavior.
No files require special attention beyond the minor style suggestion in extensions/slack/src/channel.ts

_{Last reviewed commit: 21038d1}

_{(2/5) Greptile learns from your feedback when you react with thumbs up/down!}

arosstale

Correct fix. allowExplicitReplyTagsWhenOff: true on the Slack dock was inconsistent with the documented behaviour — replyToMode: "off" should disable all threading including explicit tags, which is what the flag name says. The doc update explaining the Slack vs Telegram difference (Slack threads hide from channel, Telegram replies stay visible) is a good addition.

greptile-apps

_{7 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-21T21:16:51Z

Additional Comments (1)

extensions/slack/src/channel.ts
update to match core behavior - set to false

The core implementation in src/channels/dock.ts:476 was changed to allowExplicitReplyTagsWhenOff: false. While this extension value isn't currently used (core takes precedence), it should be updated to stay consistent.

    allowExplicitReplyTagsWhenOff: false,

Prompt To Fix With AI

This is a comment left during a code review.
Path: extensions/slack/src/channel.ts
Line: 180

Comment:
update to match core behavior - set to `false`

The core implementation in `src/channels/dock.ts:476` was changed to `allowExplicitReplyTagsWhenOff: false`. While this extension value isn't currently used (core takes precedence), it should be updated to stay consistent.

```suggestion
    allowExplicitReplyTagsWhenOff: false,
```

How can I resolve this? If you propose a fix, please make it concise.

Three independent bugs caused Slack replies to always create threads even when replyToMode was set to 'off': 1. Typing indicator created threads via statusThreadTs fallback (openclaw#16868) - resolveSlackThreadTargets fell back to messageTs for statusThreadTs - 'is typing...' was posted as thread reply, creating a thread - Fix: remove messageTs fallback, let statusThreadTs be undefined 2. [[reply_to_current]] tags bypassed replyToMode entirely (openclaw#16080) - Slack dock had allowExplicitReplyTagsWhenOff: true - Reply tags from system prompt always threaded regardless of config - Fix: set allowExplicitReplyTagsWhenOff to false for Slack 3. Contradictory replyToMode defaults in codebase (openclaw#20827) - monitor/provider.ts defaulted to 'all' - accounts.ts defaulted to 'off' (matching docs) - Fix: align provider.ts default to 'off' per documentation Fixes: openclaw#16868, openclaw#16080, openclaw#20827

vincentkoc · 2026-02-22T17:55:06Z

Maintainer triage pass (strict): this is the canonical PR for the Slack replyToMode: "off" threading cluster.

Current blocker is CI check failing on unrelated workspace-wide TypeScript test typing errors (multiple files outside this PR). I confirmed no direct failures from the files changed in this PR.

To make this merge-ready:

Rebase/update this branch on latest main and rerun checks.
Add one Unreleased changelog bullet under ## 2026.2.20 (Unreleased) -> ### Fixes for this Slack threading fix cluster.
Keep issue links in the PR body as canonical closure mapping: #16868, #16080, #20827.

If needed, I can re-run a final dedupe sweep right before merge.

vincentkoc · 2026-02-22T18:07:20Z

Thanks for driving the canonical fix path here.

I’m closing this in favor of #23799, which rebases this work on latest main, keeps your replyToMode: "off" fixes, and folds in the DM typing-thread override from #18036 so the cluster is merge-ready in one branch.

Credit is preserved from this PR and #18036 in the replacement branch. If anything is missing, call it out and I’ll reopen immediately.

openclaw-barnacle bot added docs Improvements or additions to documentation channel: slack Channel integration: slack size: XS labels Feb 21, 2026

arosstale approved these changes Feb 21, 2026

View reviewed changes

greptile-apps bot reviewed Feb 21, 2026

View reviewed changes

unboxed-ai force-pushed the fix/slack-replytomode-off branch from 21038d1 to 41abcb3 Compare February 21, 2026 21:29

openclaw-barnacle bot added gateway Gateway runtime commands Command implementations agents Agent runtime and tooling size: S and removed size: XS labels Feb 21, 2026

unboxed-ai mentioned this pull request Feb 21, 2026

fix: prevent stale threadId from routing subagent announces to wrong Slack threads #22982

Closed

unboxed-ai force-pushed the fix/slack-replytomode-off branch from 5cc73e3 to bfe7cfe Compare February 21, 2026 22:02

openclaw-barnacle bot added size: XS and removed gateway Gateway runtime commands Command implementations agents Agent runtime and tooling size: S labels Feb 21, 2026

vincentkoc mentioned this pull request Feb 22, 2026

fix(slack): finalize replyToMode off threading behavior #23799

Merged

vincentkoc closed this Feb 22, 2026

vincentkoc added dedupe:child Duplicate issue/PR child in dedupe cluster close:duplicate Closed as duplicate labels Feb 22, 2026

unboxed-ai deleted the fix/slack-replytomode-off branch February 22, 2026 20:58

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix: make replyToMode 'off' actually prevent threading in Slack#22944

fix: make replyToMode 'off' actually prevent threading in Slack#22944
unboxed-ai wants to merge 1 commit intoopenclaw:mainfrom
ghostwater-ai:fix/slack-replytomode-off

unboxed-ai commented Feb 21, 2026 •

edited by greptile-apps bot

Loading

Uh oh!

arosstale left a comment

Uh oh!

greptile-apps bot left a comment

Uh oh!

greptile-apps bot commented Feb 21, 2026

Uh oh!

vincentkoc commented Feb 22, 2026

Uh oh!

vincentkoc commented Feb 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

unboxed-ai commented Feb 21, 2026 • edited by greptile-apps bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Migration Note

Testing

Code Review Discussion

Greptile Summary

Confidence Score: 5/5

Uh oh!

arosstale left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot commented Feb 21, 2026

Uh oh!

vincentkoc commented Feb 22, 2026

Uh oh!

vincentkoc commented Feb 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

unboxed-ai commented Feb 21, 2026 •

edited by greptile-apps bot

Loading