Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
When an image_generate background task completes for a Discord session, the completion wake can cause the requester session to call the message tool multiple times with the same generated attachment, producing duplicate image posts.
Steps to reproduce
- In a Discord channel session, ask the agent to generate an image that should be delivered back to the original chat.
- Let
image_generate start a background task.
- Wait for the
image_generate:<taskId>:ok completion wake to route back to the requester session.
- Observe the completion run calling
message action="send" multiple times with the same generated media path.
This was observed twice in the same Discord session. The second observed run had prior duplicate message tool calls in the session history, which appears to make the completion agent repeat the same delivery pattern.
Expected behavior
A completed image_generate task should deliver each generated attachment exactly once to the original chat, then stop. Historical tool calls in the requester session should not be able to cause repeated delivery of the same completion artifact.
Actual behavior
The completion run sent the same generated attachment repeatedly with slightly different captions, then ended cleanly. This was a bounded bad completion run, not an infinite Discord inbound loop and not a Discord retry.
Observed evidence:
OpenClaw 2026.5.27-beta.1 (a9aaeea)
Run: image_generate:b1d29923-c15e-4869-9202-50cc850b0ff8:ok
Trace artifact:
toolMetas: 8 x message
unique media path: ~/.openclaw/media/tool-image-generation/image-1---540298e1-9377-41da-a8c6-5f03f8b540e8.jpg
captions included:
- "last 6 hours in #bots-everywhere, illustrated ..."
- "here's the last 6 hours of chaos ..."
- "the last 6 hours of this beautiful chaos ..."
- "the last 6 hours of #bots-everywhere ..."
- "last 6 hours of this beautiful chaos ..."
- "6 hours of chaos, illustrated ..."
- "here's the last 6 hours of chaos ..."
- "here's the last 6 hours of chaos in one image ..."
Earlier observed run:
Run: image_generate:287f57b0-7168-4957-8057-ba9b8cc19676:ok
toolMetas: 7 x message
unique media path: ~/.openclaw/media/tool-image-generation/image-1---9343e414-33a6-4a66-b256-3d9e2ad14591.jpg
The public channel showed 8 duplicate image posts from the second run over about 55 seconds, all using the same generated file.
OpenClaw version
2026.5.27-beta.1 (a9aaeea)
Operating system
Ubuntu 24.04.4 LTS
Install method
npm global
Model
ollama/glm-5.1:cloud for the Discord agent session. The exact image-generation provider/model was not captured in the available evidence.
Provider / routing chain
OpenClaw Discord channel -> agent session -> Ollama Cloud model for the requester/completion session; image_generate background task completion routed back through OpenClaw's inter-session completion wake path.
Additional provider/model setup details
The bug appears tied to completion delivery routing, not to image generation itself. The image file was generated successfully once; the repeated behavior happened after completion wake, during message-tool delivery.
Logs, screenshots, and evidence
# Completion delivery source in the installed 2026.5.27-beta.1 bundle
openclaw-tools-BotdYYdo.js:
function buildMediaGenerationReplyInstruction(params) {
if (params.status === "ok") return [
`The ${params.completionLabel} is ready for the original chat.`,
"This route requires message-tool delivery: the user will NOT see your normal assistant final reply.",
"Call the message tool with action=\"send\" to the original/current chat, put a short caption in the message, and attach every structured attachment from the internal event.",
`After the message tool succeeds, reply only ${SILENT_REPLY_TOKEN}.`,
"Do not rely on text-only output; the media must be sent as message-tool attachments."
].join(" ");
const delivery = await deliverSubagentAnnouncement({
requesterSessionKey: params.handle.requesterSessionKey,
targetRequesterSessionKey: params.handle.requesterSessionKey,
announceId,
triggerMessage,
steerMessage: triggerMessage,
internalEvents,
...
sourceSessionKey: `${params.toolName}:${params.handle.taskId}`,
sourceChannel: INTERNAL_MESSAGE_CHANNEL,
sourceTool: params.toolName,
expectsCompletionMessage: true,
bestEffortDeliver: true,
directIdempotencyKey: announceId
});
The source path above delegates completion delivery to an LLM-driven requester-session wake with prompt instructions. There is no observed hard guard that stops additional message.send calls after the first successful send for the same image_generate:<taskId>:ok artifact.
Related but distinct prior issue: #84605 reported image-generation completion attachments not reaching Discord. In this case delivery succeeds, but succeeds multiple times.
Impact and severity
Affected: Discord sessions using image_generate background-task completion delivery.
Severity: Medium. It does not crash the gateway and it stopped by itself, but it can spam a channel, repeat uploads, waste tool/provider work, and confuse users.
Frequency: Observed 2/2 image completion deliveries in the affected session after the completion context had historical media-send tool calls. Broader frequency is NOT_ENOUGH_INFO.
Consequence: Duplicate generated images are posted to the original Discord channel from a single completed generation task.
Additional information
Likely root cause: wakeMediaGenerationTaskCompletion() routes a successful image generation completion back into the requester session via deliverSubagentAnnouncement() and relies on prompt obedience to send exactly once. If the requester session history already contains historical message tool calls/results from a previous image completion, the model can repeat that pattern and call message.send multiple times with the same attachment.
Suggested fixes:
- Prefer deterministic direct completion delivery for generated media, without waking an LLM to decide how many times to send the same artifact.
- Add an idempotency guard keyed by
image_generate:<taskId>:ok + target + mediaUrls so only one successful media delivery is allowed per completion artifact.
- If the LLM completion route stays, stop the completion run after the first successful
message.send carrying the completion artifact.
Update: reproduced on 2026.5.28-beta.1 after closure
This is still reproducible after updating the affected instance to 2026.5.28-beta.1 (84fd629), which contains the message-tool terminal guard referenced by the bot closure comment.
New run evidence:
Run: image_generate:5e66cfd7-9cff-4edd-86b5-85d5aec8e2fe:ok
Session key: agent:main:discord:channel:1507887702379335791
Media path: ~/.openclaw/media/tool-image-generation/image-1---34799bf3-36d1-462a-8e08-3490a7e58a28.jpg
Message tool calls with that exact path: 12
Successful message tool results: 12
Delivery mirror idempotency keys: 12
Visible Discord posts with the same attachment filename: 12
The claimed fix is not sufficient for this path because the current terminal guard explicitly skips sends with route keys, and this reproduction used explicit routes (channel, target, or both) on every duplicate send. See the reopening comment for the full receipt list and source citations.
Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
When an
image_generatebackground task completes for a Discord session, the completion wake can cause the requester session to call themessagetool multiple times with the same generated attachment, producing duplicate image posts.Steps to reproduce
image_generatestart a background task.image_generate:<taskId>:okcompletion wake to route back to the requester session.message action="send"multiple times with the same generated media path.This was observed twice in the same Discord session. The second observed run had prior duplicate
messagetool calls in the session history, which appears to make the completion agent repeat the same delivery pattern.Expected behavior
A completed
image_generatetask should deliver each generated attachment exactly once to the original chat, then stop. Historical tool calls in the requester session should not be able to cause repeated delivery of the same completion artifact.Actual behavior
The completion run sent the same generated attachment repeatedly with slightly different captions, then ended cleanly. This was a bounded bad completion run, not an infinite Discord inbound loop and not a Discord retry.
Observed evidence:
The public channel showed 8 duplicate image posts from the second run over about 55 seconds, all using the same generated file.
OpenClaw version
2026.5.27-beta.1 (a9aaeea)
Operating system
Ubuntu 24.04.4 LTS
Install method
npm global
Model
ollama/glm-5.1:cloud for the Discord agent session. The exact image-generation provider/model was not captured in the available evidence.
Provider / routing chain
OpenClaw Discord channel -> agent session -> Ollama Cloud model for the requester/completion session;
image_generatebackground task completion routed back through OpenClaw's inter-session completion wake path.Additional provider/model setup details
The bug appears tied to completion delivery routing, not to image generation itself. The image file was generated successfully once; the repeated behavior happened after completion wake, during message-tool delivery.
Logs, screenshots, and evidence
The source path above delegates completion delivery to an LLM-driven requester-session wake with prompt instructions. There is no observed hard guard that stops additional
message.sendcalls after the first successful send for the sameimage_generate:<taskId>:okartifact.Related but distinct prior issue: #84605 reported image-generation completion attachments not reaching Discord. In this case delivery succeeds, but succeeds multiple times.
Impact and severity
Affected: Discord sessions using
image_generatebackground-task completion delivery.Severity: Medium. It does not crash the gateway and it stopped by itself, but it can spam a channel, repeat uploads, waste tool/provider work, and confuse users.
Frequency: Observed 2/2 image completion deliveries in the affected session after the completion context had historical media-send tool calls. Broader frequency is NOT_ENOUGH_INFO.
Consequence: Duplicate generated images are posted to the original Discord channel from a single completed generation task.
Additional information
Likely root cause:
wakeMediaGenerationTaskCompletion()routes a successful image generation completion back into the requester session viadeliverSubagentAnnouncement()and relies on prompt obedience to send exactly once. If the requester session history already contains historicalmessagetool calls/results from a previous image completion, the model can repeat that pattern and callmessage.sendmultiple times with the same attachment.Suggested fixes:
image_generate:<taskId>:ok + target + mediaUrlsso only one successful media delivery is allowed per completion artifact.message.sendcarrying the completion artifact.Update: reproduced on 2026.5.28-beta.1 after closure
This is still reproducible after updating the affected instance to
2026.5.28-beta.1 (84fd629), which contains the message-tool terminal guard referenced by the bot closure comment.New run evidence:
The claimed fix is not sufficient for this path because the current terminal guard explicitly skips sends with route keys, and this reproduction used explicit routes (
channel,target, or both) on every duplicate send. See the reopening comment for the full receipt list and source citations.