openclaw - 💡(How to fix) Fix [Bug]: Discord/Telegram channel reply silently dropped for local LLM providers since v2026.4.27 — plain-text response not delivered when agent does not call message tool [2 comments, 3 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Since v2026.4.27 changed the default group/channel reply mode to message_tool-only, agents backed by local LLMs (e.g. LM Studio + Gemma) that return plain-text responses without calling the message(action=send) tool produce no visible reply in Discord or Telegram channels, even though the response is fully generated and written to the session JSONL.

Steps to reproduce

1. Install OpenClaw v2026.4.27 or later (tested through v2026.5.2). 2. Configure a channel agent bound to a Discord channel with a local LLM provider via LM Studio (api: openai-completions, model: e.g. gemma-4-26b-a4b-it). 3. Do NOT set messages.groupChat.visibleReplies in openclaw.json (leave as default). 4. Send any chat message to the Discord channel from a user account. 5. Observe: LM Studio generates a complete response (log shows "Finished streaming response"); session JSONL records the full assistant message with stopReason: "stop"; OpenClaw Control UI shows the response — but Discord channel receives nothing.

Expected behavior

Prior to v2026.4.27 (confirmed working on v2026.4.26): the agent's text response is delivered to the Discord channel automatically, regardless of whether the message(action=send) tool is explicitly called.

Actual behavior

The LLM response is fully generated (LM Studio log: "Finished streaming response"), recorded in the session JSONL (role: assistant, stopReason: "stop"), and visible in the OpenClaw Control UI — but no message appears in the Discord channel. The delivery silently fails with no error logged to the user. The OpenClaw Control UI chat even displays Gemma explaining: "如果是直接在後台處理（沒用 message(action=send)），訊息就不會跑到你的 Discord 頻道裡" — confirming the model is aware it did not call the message tool.

OpenClaw version

v2026.5.2 (8b2a6e5) — regression first observed at v2026.4.27, persists through v2026.4.29 and v2026.5.2

Operating system

WSL2 Ubuntu 24.04.3 LTS (Linux 6.6.87.2-microsoft-standard-WSL2 x86_64), Node 22.22.0

Install method

npm global install: npm install -g openclaw Install root: /home/ser/.npm-global/lib/node_modules/openclaw

Model

lmstudio/gemma-4-26b-a4b-it (unsloth/gemma-4-26B-A4B-it-GGUF, Q4_K_XL, 19.38 GB)

Provider / routing chain

LM Studio local server @ 192.168.1.109:1234 → /v1/chat/completions openclaw.json provider: lmstudio, api: openai-completions Channel agent: flash-channel, bound to Discord channel No fallback triggered (model responds normally, stopReason: stop)

Additional provider/model setup details

• messages.groupChat was set to {} (empty, no visibleReplies key) — using default behavior
• tools block: web, media, sessions, agentToAgent, elevated, exec — no explicit message tool entry
• Local LLM (Gemma GGUF) generates plain-text responses only; it does not autonomously call OpenClaw-specific tools such as message(action=send)
• Workaround confirmed: setting messages.groupChat.visibleReplies to "automatic" via openclaw config set messages.groupChat.visibleReplies automatic and restarting the gateway restores delivery

Logs, screenshots, and evidence

LM Studio server log (normal completion, no error):
  [INFO] [gemma-4-26b-a4b-it] Finished streaming response

Session JSONL entry written successfully:
  {"type":"message","message":{"role":"assistant",
   "content":[{"type":"thinking",...},{"type":"text","text":"早啊..."}],
   "api":"openai-completions","provider":"lmstudio",
   "stopReason":"stop","usage":{"input":31510,"output":61}}}

OpenClaw Control UI: full response visible
Discord channel: no message delivered

Note: #74868 (v2026.4.29) claims to fix "auto-fallback when message tool unavailable" -- but this fix does not apply here because the message tool IS available; the local model simply does not call it. The fix addresses tool unavailability, not tool non-invocation by plain-text models.

Impact and severity

• Affected users: all users running local LLM providers (LM Studio, Ollama, llama.cpp, etc.) with Discord or Telegram channel agents on v2026.4.27+
• Severity: blocks workflow -- the bot appears online and functional (slash commands work, LLM generates responses) but all chat replies are silently discarded
• Frequency: 100% reproducible with local LLM + default config
• Consequence: users upgrading from v2026.4.26 to any later version lose all channel chat functionality with no error message, making diagnosis extremely difficult
• Cloud API users (GPT-5.5, Claude, Gemini) are unaffected because those models autonomously call the message tool when given appropriate context

Additional information

Last known good version: v2026.4.26 First known bad version: v2026.4.27 (introduced message_tool-only default for group/channel replies)

The design intent (private-by-default to reduce Discord server noise) is understood and reasonable for multi-user servers. The gap is that local LLMs are not trained to call OpenClaw-internal tools like message(action=send), so they always fall through to the silent-drop path.

Suggested fix options (either/or):

1. When visibleReplies is not explicitly set and the model returns a plain-text response without calling message tool, fall back to direct delivery (extend #74868 logic to cover non-invocation, not just unavailability).
2. Add a detection note in openclaw doctor when lmstudio/ollama provider is configured and visibleReplies is not set, suggesting visibleReplies: automatic.
3. Document visibleReplies: automatic as the recommended setting for local LLM channel agents.