Summary

When an agent uses the image_generate tool in response to a Slack DM, the generated image is uploaded to Slack twice (two separate file objects with identical content) from two independent dispatch paths in the pi-embedded runner. Behavior reproduces on v2026.4.9 and, with different file names, on v2026.4.11-beta.1.

Same class also affects music_generate and video_generate since they use the identical tool-result shape.

Reproduction

1. Configure a Slack channel on the gateway and an image_generate provider (e.g., openai/gpt-image-1) via agents.defaults.imageGenerationModel.primary.
2. From a Slack DM with the bot, send send me a picture of a goat (or any image-generation prompt).
3. Observe Slack conversation history via conversations.history. The bot response contains two separate file uploads with the same locally-generated filename but different Slack file_id values:

{ ts: T+0, file: "image-1---<uuid>.png", file_id: "F0ABC..." }
{ ts: T+2, file: "image-1---<uuid>.png", file_id: "F0XYZ..." }
{ ts: T+5, text: "<caption>" }

The two uploads are 1–5 seconds apart; both are emitted by the same gateway turn.

Root cause

image_generate tool result returns both:

// pi-embedded-Vw-lS5ti.js:6758 (v2026.4.9)
return {
  content: [{ type: "text", text: `Generated ... image.\nMEDIA:${path}` }],
  details: {
    media: { mediaUrls: savedImages.map(i => i.path) },
    paths: [...],
    ...
  }
};

The tool-result dispatcher (emitToolResultOutput in pi-embedded-Vw-lS5ti.js around line 28460 on v2026.4.9) then dispatches this result via two independent code paths in a single agent turn:

Path 1 — emitToolOutput via emitToolResultMessage

// pi-embedded-Vw-lS5ti.js:29346
const emitToolResultMessage = (toolName, message, result) => {
  if (!params.onToolResult) return;
  const { text: cleanedText, mediaUrls } = parseReplyDirectives(message);
  const filteredMediaUrls = filterToolResultMediaUrls(toolName, mediaUrls ?? [], result);
  if (!cleanedText && filteredMediaUrls.length === 0) return;
  params.onToolResult({ text: cleanedText, mediaUrls: filteredMediaUrls });
};

parseReplyDirectives extracts MEDIA: lines from the tool output text and produces mediaUrls. Then onToolResult dispatches that payload to the channel.

Path 2 — queuePendingToolMedia via extractToolResultMediaArtifact

// pi-embedded-Vw-lS5ti.js:~28522
const mediaReply = extractToolResultMediaArtifact(result);
// reads result.details.media.mediaUrls
...
queuePendingToolMedia(ctx, { mediaUrls: pendingMediaUrls, ... });

The pending media is then merged into the next assistant block reply via consumePendingToolMediaIntoReply (line 29201) and dispatched through emitBlockReply → Slack.

Existing dedupe is incomplete

Lines 28516–28525 attempt dedupe:

if (ctx.params.toolResultFormat === "plain")
  emittedToolOutputMediaUrls = collectEmittedToolOutputMediaUrls(toolName, outputText, result);
ctx.emitToolOutput(toolName, meta, outputText, result);
...
const pendingMediaUrls = mediaReply.audioAsVoice || emittedToolOutputMediaUrls.length === 0
  ? mediaUrls
  : mediaUrls.filter((url) => !emittedToolOutputMediaUrls.includes(url));

Two issues with the dedupe:

1. Format gate: the collectEmittedToolOutputMediaUrls call is gated on toolResultFormat === "plain". Any non-plain format leaves emittedToolOutputMediaUrls empty and the filter becomes a no-op — which applies to most real agent runs.
2. Cross-path gap even with plain: the deduper only filters the extractToolResultMediaArtifact → queuePendingToolMedia path against what collectEmittedToolOutputMediaUrls scraped from the output text. The actual emitToolResultMessage dispatch still fires whether or not the dedupe filter fires, because the dedupe only affects the subsequent queue, not the current emit.

So both paths end up delivering the same file via different Slack file uploads (files.completeUploadExternal called twice with the same local buffer).

Suggested fix direction

Two independent directions, either would close the double-dispatch:

Option A — tool result should dispatch media once

In emitToolResultOutput, either:

• Have emitToolResultMessage NOT inject filteredMediaUrls into the onToolResult payload when the result has details.media (let extractToolResultMediaArtifact + queuePendingToolMedia handle it), OR
• Have extractToolResultMediaArtifact return undefined (or an empty result) when emitToolResultMessage already dispatched the same media URLs via the tool-output path.

Either path eliminates one of the two dispatches. Moving the format gate to cover both paths isn't enough — the current emit still fires regardless of format.

Option B — image_generate should pick one delivery style

In createImageGenerationTool (pi-embedded-Vw-lS5ti.js:~6660), emit either MEDIA: lines in content.text or details.media.mediaUrls, not both:

return {
  content: [{ type: "text", text: `Generated ${n} image${s} with ${provider}/${model}.` }],
  details: {
    media: { mediaUrls: savedImages.map(i => i.path) },
    ...
  }
};

(Drop the ...savedImages.map(image => MEDIA:${image.path}) lines from the content text.)

This is the tighter fix — the tool then returns structured media only, and the dispatcher's structured path delivers it. music_generate and video_generate should get the same treatment.

Environment

• openclaw: v2026.4.9 (host) + v2026.4.11-beta.1 (sandbox, reproduces identically with renamed bundle files)
• node: 22.22.1
• Primary model: openai/gpt-5.4 (also reproduced under nvidia-nim/moonshotai/kimi-k2.5 and minimax/MiniMax-M2.7)
• Channel: Slack (DM)
• Tool: image_generate via openai/gpt-image-1

Local workaround

Operator-side workaround applied while this is pending: dedupe at the uploadSlackFile chokepoint in send-pJvSRc2i.js:287 via a short-window module-level Map keyed by (channelId, mediaUrl). Brutal but catches every upstream path without needing to trace them all. Happy to share the script if helpful — it's intentionally not a proposed PR because the structural fix belongs in emitToolResultOutput or the tool definition itself, not at the send chokepoint.