#Duplicate Messages When Subagents Are Spawned
1 messages · Page 1 of 1 (latest)
This symptom (“the 2nd-to-last block gets re-sent right after the response finishes”) is almost always block streaming + tool boundaries. Sub-agent completion is delivered via an internal follow-up agent call, and there’s a known bug where the block-reply coalescer flushes, then flushes again around tool execution.
The relevant tracked bug is here, and it was fixed on main via PR #16275:
2 quick things to check / try
- What version are you on?
Please paste:
openclaw --version
If you’re on an older build, upgrading is the real fix.
- Disable block streaming for Discord (workaround)
If you have block streaming enabled, turn it off and rely on Discord “preview streaming” instead.
In config, remove/disable:
{
channels: {
discord: {
blockStreaming: false,
},
},
agents: {
defaults: {
blockStreamingDefault: "off",
},
},
}
(Streaming docs for reference: https://docs.openclaw.ai/concepts/streaming)
If you still see it with block streaming OFF
Then it’s likely a separate duplicate-send/retry path. In that case, paste:
- your
channels.discord.streaming/channels.discord.blockStreamingsettings - a tiny repro description (does it only happen on subagent completion? only when replies are long enough to split?)
…and if it reproduces on the latest version, it’s 100% GitHub-issue-worthy.
Got it — BlueBubbles changes the surface, but the underlying mechanism is the same: BlueBubbles delivery uses the same block-reply / chunking pipeline, so the “2nd-to-last chunk repeats right after the reply finishes” still matches the known block streaming + tool-boundary duplication bug (sub-agent completion is delivered via an internal tool/follow-up).
First check: is BlueBubbles block streaming enabled?
In your config, if you have this:
channels: {
bluebubbles: {
blockStreaming: true,
},
}
Try flipping it off as an A/B test:
channels: {
bluebubbles: {
blockStreaming: false, // default
},
}
With block streaming off, OpenClaw should only send at the end (still chunking at channels.bluebubbles.textChunkLimit, default 4000), and the “late duplicate” usually disappears.
Second check: what OpenClaw version?
Please paste:
openclaw --version
The fix you’re describing is the one tracked as “rapid-fire duplicate messages during tool execution” (closed by PR #16275):
https://github.com/openclaw/openclaw/issues/22258
If you’re on an older build, upgrading is the real solution.
If you need streaming (blockStreaming=true)
A mitigation is to make streaming less “live” around tool calls by using end-flush behavior:
agents: {
defaults: {
blockStreamingBreak: "message_end",
},
}
(That reduces weird mid-reply flushes, at the cost of less incremental output.)
If you paste your channels.bluebubbles + agents.defaults.blockStreaming* config block, I can tell you which toggle is most likely causing the duplicate in your setup.
No need to ping the bot here — I’ll see it.
If this is BlueBubbles, then the thing to look at is almost always BlueBubbles block streaming:
- When
channels.bluebubbles.blockStreaming: true, replies are emitted as multiple “block” messages while the run is still in progress. - Sub-agent completion is delivered via an internal follow-up/tool boundary, and that’s exactly where the known “late duplicate block” bug shows up (the 2nd-to-last chunk repeats right after the run finishes).
What to do (BlueBubbles)
- Check whether you enabled block streaming
Open your config and look for:
channels: {
bluebubbles: {
blockStreaming: true,
},
}
If it’s there, flip it to false (or remove it; default is false), restart gateway, and re-test.
- Paste your version
Please paste:
openclaw --version
Because the fix landed in the “rapid-fire duplicate messages during tool execution” line of bugs (tracked here):
https://github.com/openclaw/openclaw/issues/22258
If you must keep blockStreaming=true
As a mitigation, set block streaming to flush at the end: