Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

message.send can fail for attachment deliveries that provide only a base64 buffer, filename, and content type, because the runtime expects an explicit media path or URL instead of hydrating the buffer into a temporary file.

Steps to reproduce

1. Call message.send with attachment data supplied only through buffer, plus filename and contentType.
2. Do not provide media, mediaUrl, path, filePath, or fileUrl.
3. Send through a normal channel delivery path.
4. Observe that the attachment flow fails instead of materializing the buffer into a temporary file and continuing through the standard send path.

Expected behavior

When buffer is present and no explicit media path/URL is supplied, the runtime should hydrate the buffer into a temporary attachment file and continue through normal channel delivery.

Actual behavior

The send path can fail because it depends on an explicit media path/URL and does not first materialize the buffer-backed attachment.

OpenClaw version

2026.4.8

Operating system

Linux 6.8.0-107-generic

Install method

pnpm global

Model

openai-codex/gpt-5.4 (issue is message/runtime dependent, not model-specific)

Provider / routing chain

openclaw -> OpenAI -> channel send path (provider path not required for reproduction)

Additional provider/model setup details

Observed in a self-hosted runtime while auditing artifact delivery flows that generate bytes in memory instead of stable on-disk files.

Logs, screenshots, and evidence

Observed behavior:
- attachment data existed as a valid base64 buffer plus filename/content type
- no explicit media path/url was present
- the runtime needed a local fix to materialize the buffer into a temp file before normal channel delivery

Relevant runtime area:
- message.send action runner / attachment hydration before channel dispatch

Impact and severity

Affected: any workflow that generates an attachment in memory and tries to send it without first persisting a local file path
Severity: High (blocks artifact delivery)
Frequency: Observed whenever the send path is buffer-only
Consequence: attachments that should be deliverable never leave the runtime unless the caller adds an extra local-file staging step

Additional information

This is related to outbound media handling, but it is narrower than #20258 / #50312 because the failure happens before path-allowlist propagation matters: there is no explicit media path yet, only a buffer-backed attachment.