#Duplicate Messages When Subagents Are Spawned

1 messages · Page 1 of 1 (latest)

gilded portal
#

When my claw spawns a subagents and gets back to me, duplicate messages are sent. The second to last message in a response gets sent again after OpenClaw sends its response messages. This is a documented issue but I haven't found any solutions.

bitter irisBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

primal cobaltBOT
#

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

  1. What version are you on?
    Please paste:
  • openclaw --version

If you’re on an older build, upgrading is the real fix.

  1. 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:

#

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.blockStreaming settings
  • 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.

gilded portal
#

its on bluebubbles not discord

#

@primal cobalt

primal cobaltBOT
#

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)

  1. 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.

  1. 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: