Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix v2026.4.27 group reply default change causes silent breakage for Slack/Telegram channel users [1 comments, 2 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#75098•Fetched 2026-05-01 05:38:10
View on GitHub
Comments
1
Participants
2
Timeline
3
Reactions
2
Author
EthanChouTWEthanChouTW
Participants
clawsweeper[bot]clawsweeper[bot]EthanChouTWEthanChouTW
Timeline (top)
closed ×1commented ×1cross-referenced ×1

Upgrading from v2026.4.26 to v2026.4.27 silently stops the bot from replying to mentions in Slack channels (and likely Discord/Telegram/Matrix groups) without any user-facing warning. The reply still appears in the Control UI / webchat transcript, but is never delivered to the originating channel.

Error Message

  • Existing users on default config experience silent regression: bot appears unresponsive in channels, no error surfaced anywhere visible.
  1. No warning, no error, no doctor output.

Root Cause

PR #73046 (commit 3c636208b0) changed the default for group/channel reply delivery from automatic to message_tool_only:

// src/auto-reply/reply/source-reply-delivery-mode.ts
if (chatType === "group" || chatType === "channel") {
  return params.cfg.messages?.groupChat?.visibleReplies === "automatic"
    ? "automatic"
    : "message_tool_only";   // ← new fallback, was effectively "automatic" before 4.27
}

This is a deliberate design change with documentation in docs/channels/groups.md, and messages.groupChat.visibleReplies: "automatic" is provided as an opt-out. The change is technically described in the v2026.4.27 changelog but under the Discord/group chats: heading — Slack/Telegram users don't typically read Discord-headed entries and miss it entirely.

Code Example

// src/auto-reply/reply/source-reply-delivery-mode.ts
if (chatType === "group" || chatType === "channel") {
  return params.cfg.messages?.groupChat?.visibleReplies === "automatic"
    ? "automatic"
    : "message_tool_only";   // ← new fallback, was effectively "automatic" before 4.27
}
RAW_BUFFERClick to expand / collapse

Summary

Upgrading from v2026.4.26 to v2026.4.27 silently stops the bot from replying to mentions in Slack channels (and likely Discord/Telegram/Matrix groups) without any user-facing warning. The reply still appears in the Control UI / webchat transcript, but is never delivered to the originating channel.

Root cause

PR #73046 (commit 3c636208b0) changed the default for group/channel reply delivery from automatic to message_tool_only:

// src/auto-reply/reply/source-reply-delivery-mode.ts
if (chatType === "group" || chatType === "channel") {
  return params.cfg.messages?.groupChat?.visibleReplies === "automatic"
    ? "automatic"
    : "message_tool_only";   // ← new fallback, was effectively "automatic" before 4.27
}

This is a deliberate design change with documentation in docs/channels/groups.md, and messages.groupChat.visibleReplies: "automatic" is provided as an opt-out. The change is technically described in the v2026.4.27 changelog but under the Discord/group chats: heading — Slack/Telegram users don't typically read Discord-headed entries and miss it entirely.

Impact

  • Existing users on default config experience silent regression: bot appears unresponsive in channels, no error surfaced anywhere visible.
  • Diagnosing requires reading transcripts, comparing to webchat delivery, then locating the directive logic — non-trivial.
  • openclaw doctor does not flag this mismatch.
  • Multi-day debugging cycle for affected users (in our case ~6 hours).

Reproduction

  1. Pre-upgrade: have any Slack/Discord/Telegram group channel enabled with default config (no explicit messages.groupChat.visibleReplies).
  2. Upgrade openclaw from 2026.4.26 → 2026.4.27.
  3. @bot hi in any enabled group/channel.
  4. Bot responds in Control UI transcript but does not reply in the channel.
  5. No warning, no error, no doctor output.

Suggested resolutions (any of the below would help)

  1. Change the default back to automatic (revert silent-breakage component of #73046, keep visibleReplies: "message_tool_only" as opt-in).
  2. Add a openclaw doctor check: if any channel/group is enabled and messages.groupChat.visibleReplies is unset, surface a high-priority warning with the migration snippet.
  3. One-time migration prompt on first 4.27 startup: detect existing group/channel configs without explicit visibleReplies and prompt or auto-set automatic.
  4. Promote the changelog entry: split the Discord/group chats: line into a top-level ⚠️ Breaking default change: group reply delivery section.

I'll send a PR for option 2 separately.

Environment

  • OpenClaw 2026.4.26 → 2026.4.27 (regression appears at 2026.4.27)
  • macOS 24.4.0 (Darwin)
  • Channels affected: Slack (verified), likely Discord/Telegram/Matrix groups (same code path)
  • Commit identified: 3c636208b0 from PR #73046

extent analysis

TL;DR

To fix the silent regression in OpenClaw v2026.4.27 where the bot stops replying to mentions in Slack channels, set messages.groupChat.visibleReplies to "automatic" in the configuration.

Guidance

  • Review the configuration for messages.groupChat.visibleReplies and set it to "automatic" if it's not already set, to opt-out of the new default behavior.
  • Check the Control UI / webchat transcript to verify if the bot is responding, but not delivering the reply to the channel.
  • Consider implementing one of the suggested resolutions, such as adding a check to openclaw doctor or prompting for migration on first startup, to prevent similar issues in the future.
  • Be aware that this change affects not only Slack, but also likely Discord, Telegram, and Matrix groups, due to the same code path being used.

Example

// Example configuration snippet
messages: {
  groupChat: {
    visibleReplies: "automatic"
  }
}

Notes

The provided fix assumes that the issue is solely due to the change in default behavior introduced in v2026.4.27. If other factors are at play, additional debugging may be necessary.

Recommendation

Apply the workaround by setting messages.groupChat.visibleReplies to "automatic" in the configuration, as this is a straightforward and effective solution to restore the previous behavior.

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…
#device allocation#model download#tokenizer error#prompt formatting#chain 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