Bug type

Regression (worked before, now fails)

Summary

Discord outbound sends through OpenClaw are returning success and a valid messageId, but the attachment never uploads. The resulting Discord message has no attachments server-side.

Steps to reproduce

Used an existing workspace image:

/home/REDACTED/.openclaw/workspace/images/generated/test-gemini-post-update.jpg

Tested with Discord message.send using:

• filePath
• path
• buffer

Expected behavior

Using the Discord message.send path with a local image or image buffer should create a Discord message with a populated attachments[] array and a visible uploaded file

Actual behavior

• OpenClaw returns success
• a Discord messageId is returned
• the message appears in Discord without the file
• querying the message via the Discord API shows:
• attachments: []

OpenClaw version

2026.3.22, reproduced again after update to 2026.3.23-2

Operating system

Ubuntu

Install method

No response

Model

GPT 5.4

Provider / routing chain

openclaw -> GPT 5.4 via API

Additional provider/model setup details

No response

Logs, screenshots, and evidence

For message `1485950046686937113`, Discord API returned:

json
{
"id": "1485950046686937113",
"content": "",
"attachments_count": 0,
"attachments": [],
"has_components": true
}

So this is not a Discord client rendering issue — the attachment never reached Discord.

Impact and severity

No response

Additional information

This does not appear to be:

• channel-specific
• session-state-specific
• image-generation-specific

It reproduces with a normal existing local image and ordinary Discord channel sends.

Current best hypothesis: the Discord send path is constructing the upload payload incorrectly for the Discord REST client.

Possibly:

• files is being embedded inside the JSON body
• instead of being passed as a top-level REST option alongside body

That would explain the current behavior:

• message itself succeeds
• Discord returns a message id
• attachment portion is silently discarded

Likely somewhere around:

• sendDiscordMedia
• buildDiscordMessagePayload
• serializePayload
• rest.post(...) option shape

There was an earlier hypothesis around mediaLocalRoots propagation, but that does not explain the observed behavior here because the issue persists after updating to 2026.3.23-2, and the file used for repro is workspace-rooted.