#Slack double messages holy shit

1 messages · Page 1 of 1 (latest)

woven creek
#

I keep getting double messages in slack responses. Is this a known bug? Tried sorting it out with openclaw docs, different settings, updating versions. No idea wtf is going on 🙁

Brenda  [11:04 PM]
Okay, I'm listening. What's the lesson? 😊 (edited) 
[11:04 PM]
Okay, I'm listening. What's the lesson? 😊

and it keeps saying "edited". help!

#

thanks Krii 🙏

#

@novel hearth **

#

I see you typing can't wait to see what it is 👀

#

spent 8 hours on trying to fix it

novel hearthBOT
#

This is a known Slack-specific failure mode in older OpenClaw versions.

1) Double messages: check your OpenClaw version first

There was a bug where the Slack SDK’s default retry policy could cause duplicate sends (the original request eventually succeeds and a retry also succeeds), which shows up exactly like “same bot message twice”. Tracked here: https://github.com/openclaw/openclaw/issues/1481

That fix is in v2026.1.22+.

Can you paste:

openclaw --version
openclaw gateway status

If you’re < 2026.1.22, update + restart the gateway and this should stop.

2) If you’re already on a fixed version: the other common cause

#

You have two gateway instances connected to Slack with the same tokens (e.g. daemon/service running + you also started openclaw gateway in a terminal). Slack will then get two responses from “the same bot user”.

Quick check:

openclaw gateway status
openclaw logs --follow

Then send one Slack message and see if the logs show the inbound being handled twice / two sends.

3) Why Slack shows “(edited)”

That part is usually “normal”: OpenClaw uses stream previews / streaming on Slack, which updates a message while the model is generating. Slack marks any updated message as edited.

If you want to reduce that behavior, try disabling Slack native streaming:

#

Yeah, that tracks — this one is infuriating because it looks like “my config is cursed”, but it’s usually just one of these two mechanical causes:

  1. Version < v2026.1.22 → Slack SDK retry policy can legitimately double-send (issue: https://github.com/openclaw/openclaw/issues/1481).
  2. Two gateways connected to Slack with the same tokens → both reply.

If you drop these two outputs, we can pin it down in one round-trip:

openclaw --version
openclaw gateway status

And if you want a quick “am I running twice?” sanity check on the host:

  • macOS: launchctl list | grep -i openclaw
  • Linux: systemctl --user status openclaw* (or whatever unit name you installed)
#

Also: the Slack “(edited)” part is usually just streaming/preview updates; if it annoys you, set:

{ channels: { slack: { streaming: false } } }


then restart the gateway.

woven creek
#

openclaw gateway status
2026.2.17

🩞 OpenClaw 2026.2.17 (4134875)
Claws out, commit in—let's ship something mildly responsible.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-19.log
Command: /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 445355, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
root@ziggi-01:~/.openclaw#

novel hearthBOT
# 
{
  channels: {
    slack: {
      streaming: false
    }
  }
}

(then restart the gateway)

If you paste openclaw --version + your channels.slack { ... } config block (redact tokens), I can tell you which of the two “double send” causes you’re hitting.

woven creek
#

"slack": {
"mode": "socket",
"signingSecret": "x",
"webhookPath": "/slack/events",
"enabled": true,
"botToken": "x",
"appToken": "x",
"userTokenReadOnly": true,
"groupPolicy": "open",
"blockStreaming": false,
"streaming": false,
"dmPolicy": "open",
"dm": {
"enabled": true,
"groupEnabled": true
},
"allowFrom": [
"*"
],
"channels": {
"C0AF9UNTE14": {
"requireMention": true
},
"C0AF9R5B1FG": {
"requireMention": true
},
"C0AFQN90BA9": {
"requireMention": false
}
}
}
},

novel hearthBOT
#

You’re on 2026.2.17, so you already have the “Slack SDK retry policy can double-send” fix from #1481. That means your doubles are almost certainly coming from one of these:

A) Two Slack connections (most common in practice)

Either:

  • two OpenClaw instances are running somewhere with the same Slack tokens, or
  • you accidentally configured multiple Slack accounts under channels.slack.accounts (each account creates its own connection; if two accounts share the same tokens you’ll get duplicate replies).

Can you paste:

openclaw channels status --probe
openclaw config get channels.slack.accounts

(If channels.slack.accounts exists and has >1 entry, try disabling/removing the extra one(s).)

B) “Edited” draft/stream preview + fallback final send (creates 2 identical messages)

#

The “(edited)” tag is OpenClaw updating a preview message while generating. If the final “replace the preview with the final answer” step fails, OpenClaw falls back to posting a new final message — so you see two identical messages, one marked edited.

Quick way to confirm: search your log for these lines:

grep -nE "slack: preview final edit failed|slack-stream: streaming API call failed" /tmp/openclaw/openclaw-2026-02-19.log | tail -n 50

Fast workaround (stops the identical double-posts)

Set Slack stream preview mode to a status stub so it can’t “match” the final text:

openclaw config set channels.slack.streamMode status_final
openclaw gateway restart

You’ll get a “Status: thinking
” message (edited) and then the final answer below — not two identical copies.

#

If you want, paste the channels status --probe output and that grep output and I’ll tell you exactly which branch you’re hitting.

woven creek
#

openclaw config get channels.slack.accounts

🩞 OpenClaw 2026.2.17 (4134875)
It's not "failing," it's "discovering new ways to configure the same thing wrong."

05:24:17 [plugins] [dashboard] registered at /live
05:24:17 [plugins] [dashboard] open http://localhost:18789/live
05:24:17 [plugins] [delivery-gate] store initialized
05:24:17 [plugins] [delivery-gate] plugin registered
05:24:17 [plugins] [exec-tasks] store initialized
05:24:17 [plugins] [exec-tasks] plugin registered
│
◇
Gateway reachable.

  • Discord default: enabled, configured, running, bot:@Ziggi, token:env, intents:content=limited, works, audit ok
  • Slack default: enabled, configured, running, bot:config, app:config, works

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

🩞 OpenClaw 2026.2.17 (4134875)
iMessage green bubble energy, but for everyone.

Config path not found: channels.slack.accounts
root@ziggi-01:~/.openclaw#

#

@novel hearth help

novel hearthBOT
#

You’re on 2026.2.17, so you already have the “Slack SDK retry causes duplicate sends” fix ✅

What you’re seeing is the other Slack behavior:

Why it shows “(edited)” even with "streaming": false

channels.slack.streaming: false only disables Slack native streaming (chat.startStream/appendStream).

OpenClaw will still do a draft/preview message while the model is generating (it posts a message, then chat.updates it as more text arrives). Slack marks those updates as edited.

Why you get the same message twice

That happens when the preview message fails to be finalized (the final chat.update fails), so OpenClaw falls back to posting the final answer as a new message → you end up with:

  • preview message (edited)
  • final message (new)
    
often identical, like in your example.

Fast fix (stops the “identical double message” symptom)

#

Set Slack to “status + final” mode, so the preview can’t become an identical copy of the final answer:

openclaw config set channels.slack.streamMode status_final
openclaw gateway restart

You’ll get a small “Status: thinking
” (edited) message, then the final answer below (once).

If you want zero “edited” messages

That requires disabling model streaming (so OpenClaw never produces partials → no preview updates at all). That’s controlled per-model (agents.defaults.models[...].streaming=false), but I need to know your current model first.

Can you paste:

openclaw models status --plain
#

Also: is this happening in DMs, channels, or both? That helps narrow down why chat.update is failing on finalize.

#

Good news: Config path not found: channels.slack.accounts means you do not have multiple Slack accounts configured. So the doubles aren’t coming from “two Slack accounts in one config”.

With your current Slack config:

  • channels.slack.streaming: false disables Slack native streaming (chat.startStream/appendStream)
  • but OpenClaw can still post a draft/preview message and then edit it while the model streams tokens → Slack shows “(edited)”
  • if the final “edit draft into final answer” step fails (rate limit / Slack API hiccup / permissions edge), OpenClaw falls back to posting the final answer as a new message → you see two identical messages, one marked edited

Fastest workaround (stops the “same message twice” look)

Switch the Slack preview behavior to a status stub:

openclaw config set channels.slack.streamMode status_final
openclaw gateway restart

Result: you’ll get an edited “Status: thinking
” message, and then one final answer below it (no more identical duplicates).

#

If you want to actually debug the root cause

Run this and paste what it prints (it’s the smoking gun when the final edit fails):

grep -nE "preview final edit failed|slack stream preview failed|slack: preview" /tmp/openclaw/openclaw-2026-02-19.log | tail -n 50

That error text will tell us if it’s rate limiting, missing scope, “cant_update_message”, etc.

woven creek
#

root@ziggi-01:~/.openclaw# openclaw config set channels.slack.streamMode status_final

🩞 OpenClaw 2026.2.17 (4134875)
If you can describe it, I can probably automate it—or at least make it funnier.

Error: Config validation failed: channels.slack: Unrecognized key: "streamMode"
root@ziggi-01:~/.openclaw#

novel hearthBOT
#

That error is real, and it explains why your config change wouldn’t stick:

channels.slack.streamMode is currently not accepted by config validation

Even though the Slack code supports a streamMode setting, the config schema for Slack doesn’t include it right now, so openclaw config set ... rejects it as an “unrecognized key”. So: you didn’t do anything wrong.

Practical workaround (no schema changes needed)

The “(edited) + duplicate” pattern is usually the draft/preview message flow. A clean way to avoid that path is to re-enable Slack native streaming (which uses Slack’s streaming APIs instead of draft+edit preview):

openclaw config set channels.slack.streaming true --json
openclaw gateway restart

This typically stops:

  • the “edited” marker on the actual answer
  • the “same answer posted twice” symptom
#

If streaming fails (missing Slack feature/scope), it should still help

Even if your Slack app isn’t fully set up for native streaming, OpenClaw will attempt it and then fall back to a normal single send — importantly, it won’t run the draft-preview updater in that mode.

One Slack-side checkbox to verify (if you want streaming to actually work)

In your Slack app:

  • enable Agents and AI Apps
  • ensure scope assistant:write is present

If you try the channels.slack.streaming=true change and you still get doubles, paste the last ~50 lines around one of the duplicate sends from:

openclaw logs --limit 200

and we’ll pinpoint whether it’s a double-inbound event vs a delivery fallback.