openclaw - 💡(How to fix) Fix [Bug]: Slack channel replies only route to web gateway — not posted visibly into the originating Slack channel [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When a user sends a message to the OpenClaw agent from within a Slack channel (public or private), the assistant's reply is delivered only to the OpenClaw web gateway. No message is posted back into the originating Slack channel. The user sees no response in Slack and must open the web gateway to read the reply.

Steps to reproduce

1. Install OpenClaw 2026.5.5 or 2026.5.6 via npm global on macOS.
2. Configure Slack in socket mode with valid bot and app tokens.
3. Confirm the gateway starts successfully and resolves Slack channels (gateway log shows slack channels resolved: ...).
4. Send a message to the agent from any public or private Slack channel.
5. Observe the assistant's response location.

Expected behavior

The assistant's reply should appear visibly in the same Slack channel where the user sent the message, without requiring the user to manually provide channel IDs or check the web gateway.

Actual behavior

The assistant's reply appears only in the OpenClaw web gateway. No message is posted into the Slack channel. This was tested repeatedly across multiple channels with consistent results.

When the user asked the agent to reply in Slack, the agent stated:

"I tried to look up the channel IDs using the Slack tool, but the available actions don't include a way to list conversations or get channel IDs by name."

And:

"The only way I can post visibly to [the channel] is by explicitly using the Slack message tool with [the channel ID]. Plain text responses stay in the web chat."

Only when the user manually provided the exact Slack channel ID and the agent explicitly called the message tool with that ID as the target did replies appear in Slack.

OpenClaw version

2026.5.5 and 2026.5.6

Operating system

macOS 26.4.1

Install method

npm global

Model

Grok 4.3, Claude Opus 4.6

Provider / routing chain

OpenClaw gateway → configured model providers (no intermediate proxy)

Additional provider/model setup details

• Slack is configured in socket mode with bot token and app token.
• The gateway successfully resolves Slack channel names to channel IDs at startup (confirmed in gateway logs: slack channels resolved: [channel_id]→[channel_name] ...).
• However, this resolution does not translate into automatic reply routing back to the originating channel. The model/agent layer must explicitly call the message tool with the correct channel ID to post visibly.
• The message tool does not include a conversations.list or channel-lookup action, so the agent cannot discover channel IDs on its own.

Logs, screenshots, and evidence

Gateway log (2026-05-05) — Slack connects and resolves channels successfully:

[channels/slack] [default] starting provider
[channels/slack] slack channels resolved: [id]→[name] (id:[id]), ... (+14)
[channels/slack] slack socket mode connected

Gateway log (2026-05-06) — openclaw doctor applied a config change including messages.groupChat.visibleReplies:

[gateway/reload] config change detected; evaluating reload
(meta.lastTouchedVersion, ..., messages.groupChat.visibleReplies, ...)

Current config after doctor repair:

"messages": {
  "groupChat": {
    "visibleReplies": "message_tool"
  }
}

This setting did not exist before the openclaw doctor run.

Slack conversation log (2026-05-05) — Multiple rounds of testing in a Slack channel showing:

• Plain-text replies from the agent did not appear in Slack.
• Only explicit message tool calls with a hardcoded channel ID produced visible Slack messages.
• The agent could not look up channel IDs using any available tool action.

Impact and severity

• Affected users/systems/channels: All users communicating with the agent via Slack channels (both public and private). Tested across 17+ channels.
• Severity: High — completely prevents the assistant from participating visibly in Slack channels.
• Frequency: 100% reproducible on every message sent in any Slack channel.
• Consequence: Users receive no reply in Slack. They must switch to the separate OpenClaw web gateway to see responses, which defeats the purpose of the Slack integration.

Additional information

Root cause analysis (two interrelated issues):

1. Missing default for messages.groupChat.visibleReplies: Without this setting explicitly set to "message_tool", the assistant's replies in group/channel contexts are only delivered to the web gateway. This setting was not present in the default configuration and had to be added by openclaw doctor --repair. This should either be the default behavior or be set automatically when a Slack channel is configured.

2. No channel-ID discovery available to the agent: Even after the visibleReplies setting is corrected, the agent must know the exact Slack channel ID to use the message tool. The gateway resolves channel names to IDs at startup (confirmed in logs), but this mapping is not exposed to the agent. The message tool's available actions (send, edit, delete, react, read, pin, etc.) do not include any way to list conversations or look up a channel ID by name. The agent must either receive the channel ID in its inbound metadata or have a lookup action available.

Workaround: Manually provide all Slack channel IDs to the agent (e.g., in a workspace notes file) and instruct it to always use the message tool with the explicit channel ID as target. This is fragile and does not scale.