Skip to content

fix(slack): respect replyToMode=off for inline directive reply tags#16113

Closed
zerone0x wants to merge 1 commit intoopenclaw:mainfrom
zerone0x:fix/slack-replytomode-off-respects-reply-tags
Closed

fix(slack): respect replyToMode=off for inline directive reply tags#16113
zerone0x wants to merge 1 commit intoopenclaw:mainfrom
zerone0x:fix/slack-replytomode-off-respects-reply-tags

Conversation

@zerone0x
Copy link
Contributor

@zerone0x zerone0x commented Feb 14, 2026

Summary

Fixes #16080

When replyToMode is set to "off" (the default), agent responses containing [[reply_to_current]] tags were still sent as Slack thread replies instead of regular channel messages. This happened because deliverReplies() used payload.replyToId (from parsed inline directives) unconditionally, bypassing the replyToMode check.

Changes

  • src/slack/monitor/replies.ts: Add optional replyToMode param to deliverReplies(). When replyToMode === "off", ignore payload.replyToId from inline directives, consistent with how the Telegram plugin handles this (line 94 of src/telegram/bot/delivery.ts).
  • src/slack/monitor/message-handler/dispatch.ts: Pass ctx.replyToMode through to deliverReplies().
  • Test update: Fixed existing test that was asserting the buggy behavior (threadTs: "555" when replyToMode: "off"). Now correctly expects threadTs: undefined. Added a new test confirming replyToId is still honored when replyToMode: "all".

Test Plan

  • All 22 Slack test files pass (144 tests)
  • Lint clean (oxlint)
  • Build succeeds
  • Verified: replyToId ignored when replyToMode: "off" (new test)
  • Verified: replyToId honored when replyToMode: "all" (new test)
  • Verified: existing threading behavior unchanged for "first" and "all" modes

🤖 Generated with Claude Code (issue-hunter-pro)

Greptile Summary

This PR fixes a bug where inline directive reply tags ([[reply_to_current]]) from agent responses were creating Slack thread replies even when replyToMode was set to "off". The fix adds a replyToMode parameter to deliverReplies() and filters out payload.replyToId when the mode is "off", aligning Slack's behavior with how Telegram already handles this case.

  • Added replyToMode parameter to deliverReplies() in src/slack/monitor/replies.ts:20
  • When replyToMode === "off", inline directive replyToId is now ignored (line 25)
  • Passes ctx.replyToMode from dispatch layer (line 118 of dispatch.ts)
  • Updated test assertion to expect threadTs: undefined when mode is "off" (previously incorrectly expected threadTs: "555")
  • Added new test confirming replyToId still works when replyToMode: "all"

Confidence Score: 5/5

  • This PR is safe to merge with minimal risk
  • The changes are minimal, focused, and well-tested. The fix mirrors the existing pattern used in Telegram (line 101 of src/telegram/bot/delivery.ts), ensuring consistency across channels. Test coverage is comprehensive with both the buggy behavior corrected and a new test for the "all" mode added. The implementation is a simple conditional check with no complex logic or side effects.
  • No files require special attention

Last reviewed commit: 2b6c139

@openclaw-barnacle
Copy link

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

@dorukardahan
Copy link
Contributor

Ported this fix to a new PR on current main: #23513

Reason: this PR is showing CONFLICTING / DIRTY, but the branch currently appears to have history divergence from current main (locally reproduces as refusing to merge unrelated histories), so it is not a simple line-level conflict to resolve.

#23513 re-applies the same behavior fix and test intent on top of current main, with updated file paths/tests and targeted verification.

Credit to @zerone0x for the original fix direction here.

@steipete
Copy link
Contributor

I built this by design that agents can override the default reply mode. What's your motivation of changing it?

@dorukardahan
Copy link
Contributor

Totally fair question — and thanks for calling that out.

The motivation here is not to remove agent overrides in general, but to treat replyToMode: "off" as a stronger operator-side policy/guardrail for Slack when the replyToId comes from inline directive tags (e.g. [[reply_to_current]]).

What we observed in practice:

  • operators set replyToMode: "off" expecting top-level replies in Slack DMs/channels
  • the model can still emit inline reply directives (sometimes intentionally, sometimes accidentally/hallucinated)
  • those directives force threading and effectively override the operator setting
  • result is surprising channel UX, especially for setups using off specifically to avoid thread sprawl

So the proposed behavior was: keep replyToMode semantics authoritative for Slack delivery when the thread target comes from an inline directive tag, while preserving normal threading for actual incoming threaded messages.

That said, if the intended design is explicitly “agents should always be able to override replyToMode via inline directives,” I’m happy to defer to that and pivot this into either:

  1. docs clarification (that replyToMode is a default, not a hard constraint), or
  2. a config flag (e.g. strict mode for Slack directive overrides)

Also, I ported the change to current main in #23513 only because this branch appears to have history divergence (unrelated histories) and couldn’t be cleanly merged forward.

@zerone0x
Copy link
Contributor Author

Closing in favor of #23513 which covers the same fix and has already received an approval. Thanks!

@zerone0x zerone0x closed this Feb 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

channel: slack Channel integration: slack size: S stale Marked as stale due to inactivity

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Slack plugin: [[reply_to_current]] tags bypass replyToMode=off

3 participants