Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix bug: visibleReplies message_tool mode silently drops replies when message tool is unavailable [2 pull requests, 2 comments, 3 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#74868•Fetched 2026-05-01 05:40:31
View on GitHub
Comments
2
Participants
3
Timeline
8
Reactions
2
Author
kagura-agentkagura-agent
Participants
clawsweeper[bot]clawsweeper[bot]kagura-agentkagura-agentsteipetesteipete
Timeline (top)
commented ×2cross-referenced ×2closed ×1mentioned ×1

When messages.groupChat.visibleReplies is set to "message_tool" (the new default in 2026.4.27), group/channel replies are suppressed and the agent is expected to use message(action=send) to post visible output. However, there is no guard to check whether the message tool is actually available to the agent. If the message tool is missing (due to tool policy, disableMessageTool, or any other reason), the agent is completely silenced — automatic delivery is suppressed, but the agent has no tool to send messages manually either.

Error Message

If visibleReplies is "message_tool" but the message tool is not in the agent's available tools, the system should fall back to "automatic" mode so replies are still delivered. The current behavior creates a silent failure with no error or warning.

Root Cause

In resolveSourceReplyDeliveryMode() (src/auto-reply/reply/source-reply-delivery-mode.ts), the decision to use message_tool_only is based purely on config — it does not check whether the message tool is actually present in the agent's tool inventory:

if (chatType === "group" || chatType === "channel") {
  return params.cfg.messages?.groupChat?.visibleReplies === "automatic"
    ? "automatic"
    : "message_tool_only";
}

This then sets suppressDelivery = true in dispatch-from-config.ts, which blocks all automatic outbound delivery.

Meanwhile, the system prompt does include a conditional availableTools.has("message") check for showing the message tool instructions section, but the unconditional line above it still tells the agent to "use message(action=send) for visible channel output" regardless.

Fix Action

Workaround

Add to openclaw.json:

{
  "messages": {
    "groupChat": {
      "visibleReplies": "automatic"
    }
  }
}

PR fix notes

PR #74877: fix(auto-reply): fall back to automatic delivery when message tool is unavailable

Description (problem / solution / changelog)

Summary

When messages.groupChat.visibleReplies is set to "message_tool" (the default since 2026.4.27), group/channel replies are suppressed and the agent is expected to use message(action=send). However, if the message tool is not available to the agent (due to tool policy allowlist, disableMessageTool, or any other reason), the agent is completely silenced — automatic delivery is suppressed, but the agent has no tool to send messages manually.

Fixes #74868

Changes

Added a messageToolAvailable guard to resolveSourceReplyDeliveryMode(): when the computed mode would be message_tool_only but the message tool is not in the agent's effective tool policy, fall back to "automatic" delivery so replies are not silently dropped.

Files changed

  • src/auto-reply/reply/source-reply-delivery-mode.ts — Added optional messageToolAvailable?: boolean parameter to resolveSourceReplyDeliveryMode() and resolveSourceReplyVisibilityPolicy(). When messageToolAvailable === false and mode would be message_tool_only, returns "automatic" instead.

  • src/auto-reply/reply/dispatch-from-config.ts — At the dispatch call site, computes message tool availability using resolveEffectiveToolPolicy() + isToolAllowedByPolicies() and passes it through. This follows the same pattern as the existing cron fix (b9d2e0f86d — canPromptForMessageTool()).

  • src/plugin-sdk/channel-reply-pipeline.ts — Passes through messageToolAvailable in resolveChannelSourceReplyDeliveryMode().

  • src/auto-reply/reply/source-reply-delivery-mode.test.ts — Added 3 test cases covering the fallback behavior for both functions.

Design decisions

  • The new parameter defaults to true (undefined = available) for full backward compatibility — no existing callers are affected.
  • Tool availability is checked at the config policy level (global + agent allow/deny), matching the resolution granularity available at the dispatch stage.

Testing

  • All 16 tests in source-reply-delivery-mode.test.ts pass (npx vitest run)
  • New tests verify: (1) fallback to automatic when unavailable, (2) no change when available/undefined, (3) visibility policy propagation

Changed files

  • src/auto-reply/reply/dispatch-from-config.ts (modified, +16/-0)
  • src/auto-reply/reply/source-reply-delivery-mode.test.ts (modified, +50/-0)
  • src/auto-reply/reply/source-reply-delivery-mode.ts (modified, +12/-2)
  • src/plugin-sdk/channel-reply-pipeline.ts (modified, +1/-0)
  • ui/src/i18n/locales/fa.ts (modified, +1/-1)

PR #75099: fix(auto-reply): surface private group replies

Description (problem / solution / changelog)

Summary

  • Problem: after 2026.4.27, group/channel source turns defaulted to private message_tool_only replies without a runtime warning or an agent-accessible config repair path.
  • Why it matters: affected Discord, Slack, Telegram, Feishu, and other group/channel rooms looked like successful runs in the dashboard while the room never received a final reply.
  • What changed: warn once when the implicit private default is first used, allow messages.visibleReplies / messages.groupChat.visibleReplies through config.patch, and fall back to automatic delivery when the message tool is unavailable.
  • What did NOT change: the intentional group/channel safety default remains private-by-default when the message tool is available.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #74876
  • Related #74842
  • Related #74868
  • Related #73046
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: #73046 intentionally changed group/channel source replies to message_tool_only, but the shared resolver applied it to every group/channel surface without an upgrade warning, without an easy config.patch repair path, and without checking whether the message tool could actually send visibly.
  • Missing detection / guardrail: no runtime warning for implicit private defaults, no config mutation allowlist entry for visible-reply keys, and no regression test for missing message tool fallback.
  • Contributing context: the changelog entry framed the change as Discord/group chats even though the resolver uses normalized group / channel chat type and therefore affects all channels.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/auto-reply/reply/source-reply-delivery-mode.test.ts, src/auto-reply/reply/dispatch-from-config.test.ts, src/agents/tools/gateway-tool-guard-coverage.test.ts
  • Scenario the test should lock in: implicit group/channel default warns and stays tool-only, unavailable message tool falls back to automatic delivery, and visible-reply config keys can be patched.
  • Why this is the smallest reliable guardrail: the bug lives in the shared resolver, dispatch policy handoff, and agent-facing config mutation guard.
  • Existing test that already covers this (if any): existing dispatch tests covered the private default, but not the warning, config repair path, or unavailable-tool fallback.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

  • Group/channel rooms still default to private final replies when message tool output is available.
  • Operators now get a one-shot warning the first time an implicit private group/channel default is applied.
  • messages.groupChat.visibleReplies = "automatic" can be applied via config.patch instead of manual JSON editing.
  • If message_tool_only is selected but the message tool is unavailable, OpenClaw now delivers the final reply automatically instead of silently dropping visible output.
  • Docs and changelog now say this applies to all group/channel chats and clarify hot reload.

Diagram (if applicable)

Before:
group/channel turn -> implicit message_tool_only -> final reply private -> room appears silent
message tool unavailable -> no visible path

After:
group/channel turn -> implicit message_tool_only -> warning + message tool visible path
message tool unavailable -> automatic delivery fallback
operator repair -> config.patch messages.groupChat.visibleReplies = "automatic"

Security Impact (required)

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No
  • New/changed network calls? No
  • Command/tool execution surface changed? Yes
  • Data access scope changed? No
  • If any Yes, explain risk + mitigation: the agent-facing gateway config mutation allowlist now permits two bounded enum config keys that affect reply visibility only. It does not allow secrets, auth, tool policy, sandbox, or network settings.

Repro + Verification

Environment

  • OS: macOS local, Blacksmith Testbox Linux CI parity
  • Runtime/container: Node 22 / pnpm
  • Model/provider: N/A
  • Integration/channel (if any): shared group/channel delivery policy; reported on Discord and all group/channel rooms
  • Relevant config (redacted): absent messages.groupChat.visibleReplies on group/channel turns

Steps

  1. Process a group/channel turn with no explicit visible-reply config.
  2. Observe source reply delivery mode and final reply dispatch behavior.
  3. Set tools.allow without message and process the same group/channel turn.
  4. Patch messages.groupChat.visibleReplies via the gateway config mutation guard.

Expected

  • Implicit default remains private-by-default but warns once.
  • Missing message tool does not silence visible output.
  • Visible-reply keys are patchable.

Actual

  • Before this PR, implicit default was silent, missing message tool could leave no visible delivery path, and the config keys were protected from config.patch.

Evidence

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios: resolver warning/default/fallback behavior, dispatch fallback to final reply delivery, gateway config mutation allowlist, docs/config metadata checks.
  • Edge cases checked: native commands still automatic; explicit automatic config still automatic; explicit tool-only remains tool-only when message is available.
  • What you did not verify: live Discord/Slack/Telegram/Feishu room roundtrip.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? Yes
  • Config/env changes? Yes
  • Migration needed? No
  • If yes, exact upgrade steps: optional operator repair remains messages.groupChat.visibleReplies = "automatic" to restore legacy room auto-posting. The gateway hot-reloads messages config unless file watching/reload is disabled.

Risks and Mitigations

  • Risk: Falling back to automatic delivery when message is unavailable could make some tool-only rooms visible again.
    • Mitigation: the fallback only applies when there is no tool path to produce visible output; when message is available, the private-by-default safety posture is unchanged.
  • Risk: config.patch could be used to change group/channel visibility.
    • Mitigation: this is the intended repair affordance and is limited to two non-secret enum keys.

Changed files

  • CHANGELOG.md (modified, +1/-1)
  • docs/.generated/config-baseline.sha256 (modified, +2/-2)
  • docs/channels/groups.md (modified, +3/-0)
  • docs/gateway/config-channels.md (modified, +2/-0)
  • src/agents/tools/gateway-tool-guard-coverage.test.ts (modified, +28/-0)
  • src/agents/tools/gateway-tool.ts (modified, +4/-0)
  • src/auto-reply/reply/dispatch-from-config.test.ts (modified, +25/-0)
  • src/auto-reply/reply/dispatch-from-config.ts (modified, +33/-0)
  • src/auto-reply/reply/source-reply-delivery-mode.test.ts (modified, +84/-1)
  • src/auto-reply/reply/source-reply-delivery-mode.ts (modified, +36/-2)
  • src/plugin-sdk/channel-reply-pipeline.ts (modified, +1/-0)

Code Example

if (chatType === "group" || chatType === "channel") {
  return params.cfg.messages?.groupChat?.visibleReplies === "automatic"
    ? "automatic"
    : "message_tool_only";
}

---

{
  "messages": {
    "groupChat": {
      "visibleReplies": "automatic"
    }
  }
}
RAW_BUFFERClick to expand / collapse

Summary

When messages.groupChat.visibleReplies is set to "message_tool" (the new default in 2026.4.27), group/channel replies are suppressed and the agent is expected to use message(action=send) to post visible output. However, there is no guard to check whether the message tool is actually available to the agent. If the message tool is missing (due to tool policy, disableMessageTool, or any other reason), the agent is completely silenced — automatic delivery is suppressed, but the agent has no tool to send messages manually either.

Steps to reproduce

  1. Upgrade to OpenClaw 2026.4.27 (which defaults messages.groupChat.visibleReplies to "message_tool")
  2. Have an agent in a Discord group/channel where the message tool is not available (e.g. tool policy whitelist that does not include message, or disableMessageTool: true)
  3. Send a message mentioning the agent in the group
  4. Agent processes the message and generates a reply, but it is never delivered to the channel — only visible in Control UI

Expected behavior

If visibleReplies is "message_tool" but the message tool is not in the agent's available tools, the system should fall back to "automatic" mode so replies are still delivered. The current behavior creates a silent failure with no error or warning.

Root cause

In resolveSourceReplyDeliveryMode() (src/auto-reply/reply/source-reply-delivery-mode.ts), the decision to use message_tool_only is based purely on config — it does not check whether the message tool is actually present in the agent's tool inventory:

if (chatType === "group" || chatType === "channel") {
  return params.cfg.messages?.groupChat?.visibleReplies === "automatic"
    ? "automatic"
    : "message_tool_only";
}

This then sets suppressDelivery = true in dispatch-from-config.ts, which blocks all automatic outbound delivery.

Meanwhile, the system prompt does include a conditional availableTools.has("message") check for showing the message tool instructions section, but the unconditional line above it still tells the agent to "use message(action=send) for visible channel output" regardless.

Suggested fix

Add a guard in resolveSourceReplyDeliveryMode() or at the dispatch level: if message_tool_only mode is selected but the message tool is not in the agent's tool inventory, fall back to "automatic". A similar pattern already exists in cron runs (commit b9d2e0f86d — "fix(cron): gate delivery prompt on message tool availability").

Workaround

Add to openclaw.json:

{
  "messages": {
    "groupChat": {
      "visibleReplies": "automatic"
    }
  }
}

Environment

  • OpenClaw 2026.4.27
  • Introduced by commit 3c636208b0 ("fix(messages): keep group replies tool-only by default")
  • Channel: Discord (likely affects all group/channel surfaces)

extent analysis

TL;DR

Add a guard in resolveSourceReplyDeliveryMode() to fall back to "automatic" mode when the message tool is not available to the agent.

Guidance

  • Check the resolveSourceReplyDeliveryMode() function in src/auto-reply/reply/source-reply-delivery-mode.ts to ensure it correctly handles the case where the message tool is not in the agent's tool inventory.
  • Verify that the availableTools.has("message") check is used to determine the delivery mode, rather than just relying on the config setting.
  • Consider adding a similar pattern to the dispatch level to ensure that suppressDelivery is not set to true when the message tool is not available.
  • As a temporary workaround, set "visibleReplies" to "automatic" in openclaw.json to prevent silent failures.

Example

if (chatType === "group" || chatType === "channel") {
  if (availableTools.has("message") && params.cfg.messages?.groupChat?.visibleReplies === "message_tool") {
    return "message_tool_only";
  } else {
    return "automatic";
  }
}

Notes

This fix assumes that the availableTools object is correctly populated with the agent's available tools. If this is not the case, additional changes may be needed to ensure that the availableTools object is correctly updated.

Recommendation

Apply the suggested fix by adding a guard in resolveSourceReplyDeliveryMode() to fall back to "automatic" mode when the message tool is not available to the agent, as this will prevent silent failures and ensure that replies are delivered correctly.

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…

FAQ

Expected behavior

If visibleReplies is "message_tool" but the message tool is not in the agent's available tools, the system should fall back to "automatic" mode so replies are still delivered. The current behavior creates a silent failure with no error or warning.

#callback error#memory management#API rate limit#retriever error#indexing 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

openclaw - ✅(Solved) Fix bug: visibleReplies message_tool mode silently drops replies when message tool is unavailable [2 pull requests, 2 comments, 3 participants]