Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Slack DMs don't receive normal replies, while channel mentions work [1 pull requests, 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#59001•Fetched 2026-04-08 02:30:11
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
wow64cpuwow64cpu
Participants
afurmafurmwow64cpuwow64cpu
Timeline (top)
closed ×1commented ×1cross-referenced ×1labeled ×1
  • Self-hosted OpenClaw
  • Slack integration via Socket Mode
  • Slack channels work
  • Slack DMs do not receive normal assistant replies, but receive technical message about pairing

Error Message

  • No obvious Slack send error was found in the logs checked so far

Root Cause

  • Self-hosted OpenClaw
  • Slack integration via Socket Mode
  • Slack channels work
  • Slack DMs do not receive normal assistant replies, but receive technical message about pairing

Fix Action

Fixed

PR fix notes

PR #59030: fix(slack): route live DM replies to the concrete DM channel

Description (problem / solution / changelog)

Summary

  • Problem: Slack DMs could receive pairing/system messages, but normal assistant replies were routed through the stored user:<id> target instead of the concrete inbound D... DM channel.
  • Why it matters: that split made the live reply path behave differently from the pairing/system path, so DM turns could reach final_answer without the user seeing the normal reply in Slack.
  • What changed: extensions/slack/src/monitor/message-handler/prepare.ts now uses channel:<dm-channel-id> as the live replyTarget for direct messages while keeping persisted routing metadata user-scoped; extensions/slack/src/monitor/message-handler/prepare.test.ts adds a regression test for that contract.
  • What did NOT change (scope boundary): stored session routing remains user:<id>, Slack channel/group reply behavior is unchanged, and no outbound adapter or token/auth logic was modified.

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 #59001
  • Related #
  • This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

  • Root cause: the Slack monitor built ctxPayload.To as user:<slack-user-id> for DM session metadata, then reused that value as the immediate live replyTarget. That is appropriate for persisted routing, but not for the current inbound DM turn where the concrete Slack DM channel id is already known.
  • Missing detection / guardrail: there was no regression test asserting that Slack DM live replies should use the inbound D... channel while persisted routing stays user-scoped.
  • Prior context (git blame, prior PR, issue, or refactor if known): unknown.
  • Why this regressed now: unknown from local inspection. I did not trace the exact introducing commit.
  • If unknown, what was ruled out: this change does not touch Slack auth, pairing authorization, or the outbound send adapter; the issue is in the monitor prepare-stage target selection.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this: Unit test
  • Target test or file: extensions/slack/src/monitor/message-handler/prepare.test.ts
  • Scenario the test should lock in: a Slack DM turn should produce replyTarget = channel:D... while preserving ctxPayload.To = user:... and NativeChannelId = D....
  • Why this is the smallest reliable guardrail: the bug is pure Slack monitor preparation logic and does not require a live Slack session to validate the target split.
  • Existing test that already covers this (if any): none.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

Slack DMs now send the live assistant reply back into the same DM channel that produced the inbound turn. Channel mentions and persisted session routing behavior are unchanged.

Diagram (if applicable)

Before:
Slack DM inbound -> ctxPayload.To = user:U123 -> live reply reuses user target -> reply can miss the active DM

After:
Slack DM inbound -> replyTarget = channel:D123 + ctxPayload.To = user:U123 -> live reply lands in the same DM -> persisted routing still works

## Changed files

- `extensions/slack/src/monitor/message-handler/prepare.test.ts` (modified, +13/-0)
- `extensions/slack/src/monitor/message-handler/prepare.ts` (modified, +5/-1)

Code Example

Useful observations:
- Slack channel replies work
- Slack DM inbound works
- DM-related technical/system messages can be delivered
- The assistant appears to generate a reply and reaches final_answer in transcripts
- No obvious Slack send error was found in the logs checked so far

Relevant config shape:

{
  "channels": {
    "slack": {
      "enabled": true,
      "mode": "socket",
      "groupPolicy": "open",
      "dm": {
        "enabled": true,
        "policy": "open",
        "allowFrom": ["*"]
      }
    }
  }
}
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

  • Self-hosted OpenClaw
  • Slack integration via Socket Mode
  • Slack channels work
  • Slack DMs do not receive normal assistant replies, but receive technical message about pairing

Steps to reproduce

  1. Set up a Slack app in Socket Mode with valid appToken and botToken.
  2. Enable Slack in OpenClaw.
  3. Configure Slack channels so the bot can reply in channels.
  4. Configure Slack DMs as open.
  5. Restart the gateway.
  6. Add bot to some Slack channel, and mention the bot: it replies correctly.
  7. Send the bot a direct message in Slack: the message is received by OpenClaw, but no normal assistant reply appears in the DM.

Expected behavior

The bot should reply normally in Slack DMs

Actual behavior

Slack channel mentions work, and Slack DM messages are received by OpenClaw, but normal assistant replies are never delivered back into the Slack DM conversation. Technical/system messages can reach the DM, so the failure seems specific to normal DM reply delivery.

OpenClaw version

v2026.3.31

Operating system

Ubuntu 24.04.4 LTS (Noble Numbat)

Install method

One-liner from oficical landing page (npm)

Model

gpt-5.4/openai-codex

Provider / routing chain

Slack app (Socket Mode) -> OpenClaw Gateway -> agent runtime (main session) -> Slack DM/channel delivery

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Useful observations:
- Slack channel replies work
- Slack DM inbound works
- DM-related technical/system messages can be delivered
- The assistant appears to generate a reply and reaches final_answer in transcripts
- No obvious Slack send error was found in the logs checked so far

Relevant config shape:

{
  "channels": {
    "slack": {
      "enabled": true,
      "mode": "socket",
      "groupPolicy": "open",
      "dm": {
        "enabled": true,
        "policy": "open",
        "allowFrom": ["*"]
      }
    }
  }
}

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The issue with Slack DMs not receiving normal assistant replies in OpenClaw may be related to the configuration or handling of DM replies, and verifying the Slack app configuration and OpenClaw's DM handling logic could help resolve the issue.

Guidance

  • Verify that the Slack app configuration, especially the dm section, is correctly set up to allow OpenClaw to send replies to DMs.
  • Check the OpenClaw logs for any errors or warnings related to DM reply delivery to ensure that there are no obvious issues with the sending process.
  • Review the groupPolicy and dm.policy settings in the config to ensure they are set to allow DM interactions.
  • Test the DM reply functionality with a different Slack app or configuration to isolate if the issue is specific to the current setup.

Example

No specific code example is provided as the issue seems to be related to configuration or logic rather than a specific code snippet.

Notes

The provided information suggests that the issue is specific to DM reply delivery and not a general problem with Slack integration, as channel replies work correctly. The fact that technical messages can be delivered to DMs indicates that the connection and authentication are working, narrowing down the potential causes.

Recommendation

Apply workaround: Given the information provided, it seems more likely that a configuration or logic issue within OpenClaw or the Slack app setup is causing the problem, rather than a version-specific bug that would be fixed by an upgrade. Therefore, applying a workaround or configuration change is recommended as the first step to resolve the issue.

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

The bot should reply normally in Slack DMs

#serialization error#model compatibility#GPU setup#container setup#orchestration issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING