openclaw - 💡(How to fix) Fix [Bug]: OpenClaw Mattermost message tool reports ok while filePath/attachments are not uploaded

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

In OpenClaw's Mattermost message bridge, message(action="send") returns ok:true for file attachment payload shapes such as filePath, attachments[].filePath, and attachments[].path, but the resulting Mattermost posts have no file_ids; the same file uploads correctly through Mattermost's REST API.

Steps to reproduce

1. Start OpenClaw with the Mattermost plugin enabled and a bot token that can post to a Mattermost DM.
2. Use the OpenClaw message tool with action: "send" and a local markdown file via attachments[].filePath.
3. Observe that the tool returns ok:true and a Mattermost post id, but the resulting Mattermost post has file_ids: [].
4. Repeat with top-level filePath and observe ok:true with file_ids: [].
5. Repeat with attachments[].path and observe ok:true with file_ids: [].
6. Repeat with buffer + filename; observe ok:true, but the uploaded file metadata is for an unrelated MP3 voice file, not the requested markdown document.
7. As a control/workaround, upload the same markdown file directly to Mattermost with POST /api/v4/files using the same bot token and DM target.
8. Create a Mattermost post with POST /api/v4/posts and the returned uploaded file id in file_ids.
9. Observe that the direct REST API control/workaround produces a real Mattermost file attachment for the same markdown file.

Expected behavior

For Mattermost delivery through OpenClaw, attachment-capable inputs should either upload the requested file and include Mattermost file_ids on the created post, or fail loudly with an explicit unsupported/malformed attachment error. Direct Mattermost REST API upload proves the target file, channel, and bot token can produce a real file attachment.

Actual behavior

The OpenClaw message tool returned ok:true for multiple Mattermost attachment attempts, but the intended markdown file was not attached for the OpenClaw filePath / attachments[] attempts.

Observed OpenClaw/Mattermost bridge results, with live ids redacted:

• Attempt 1 (attachments[].filePath): OpenClaw returned ok:true; resulting Mattermost post had file_ids: [].
• Attempt 2 (top-level filePath): OpenClaw returned ok:true; resulting Mattermost post had file_ids: [].
• Attempt 3 (attachments[].path): OpenClaw returned ok:true; resulting Mattermost post had file_ids: [].
• Attempt 4 (buffer + filename): OpenClaw returned ok:true; resulting Mattermost post had a file_ids entry, but the uploaded file metadata was for an unrelated MP3 voice file, not the requested markdown document.

Successful control/workaround:

• The same markdown file was uploaded directly to Mattermost with POST /api/v4/files using the same bot token and DM target.
• A direct POST /api/v4/posts call then attached the returned uploaded file id via file_ids.
• That direct REST API path produced the correct, real Mattermost markdown attachment.

This isolates the failure to OpenClaw's Mattermost message bridge/tool delivery path rather than Mattermost's file upload API, the bot token, the DM target, or the source file.

OpenClaw version

OpenClaw 2026.5.26-beta.2 (7d89681)

Operating system

macOS 26.3.1

Install method

Global OpenClaw npm package under the Homebrew prefix, launched by a macOS LaunchAgent for the OpenClaw gateway. User path, local service port, and host details redacted.

Model

openai-codex/gpt-5.5 (effective assistant model; bug is in Mattermost message bridge/tool delivery)

Provider / routing chain

OpenClaw message tool -> Mattermost plugin/bridge -> Mattermost REST API (base URL and bot token redacted)

Additional provider/model setup details

OpenClaw was running as the gateway process from a globally installed OpenClaw package under the Homebrew prefix, launched through a macOS LaunchAgent. The Mattermost account used the configured OpenClaw Mattermost bot token and base URL; both are redacted. The target surface was a Mattermost direct-message channel. The failure occurs after the assistant emits the OpenClaw message tool call: OpenClaw reports success, but the resulting Mattermost post metadata does not include the intended uploaded file.

Logs, screenshots, and evidence

Runtime evidence, redacted:
- `openclaw --version` returned `OpenClaw 2026.5.26-beta.2 (7d89681)`.
- macOS reported `26.3.1`.
- launchctl showed the OpenClaw gateway running as a macOS LaunchAgent.
- The LaunchAgent runs Node from the Homebrew prefix and OpenClaw from the global npm package path.
- Local user path, service port, private network address, bot token, DM/channel id, post ids, and file ids are intentionally redacted.

Source artifact evidence, redacted:
- Requested source file was a local markdown document.
- Size: `12563` bytes.
- Type: ASCII markdown / `text/markdown; charset=utf-8`.

OpenClaw tool attempts:
- `attachments[].filePath`: tool returned `ok:true`; resulting Mattermost post had `file_ids: []`.
- Top-level `filePath`: tool returned `ok:true`; resulting Mattermost post had `file_ids: []`.
- `attachments[].path`: tool returned `ok:true`; resulting Mattermost post had `file_ids: []`.
- `buffer` + `filename`: tool returned `ok:true`; resulting Mattermost post had a file id, but file metadata showed an unrelated MP3 voice file rather than the requested markdown document.

Control test:
- Direct Mattermost REST API upload with the same bot token, same DM target, and same markdown file succeeded.
- Direct `/api/v4/files` returned the expected uploaded markdown file metadata, including `12563` byte size and `text/markdown; charset=utf-8` MIME type.
- Direct `/api/v4/posts` with that uploaded file id produced a real Mattermost file attachment.

Code path observed in the local OpenClaw checkout:
- `openclaw/src/agents/tools/message-tool.ts` exposes attachment-related fields such as `filePath`, `path`, `buffer`, `filename`, and `mimeType`.
- `openclaw/src/infra/outbound/message-action-params.ts` only hydrates file attachments for specific non-Mattermost actions such as `sendAttachment`, `setGroupIcon`, and BlueBubbles `upload-file`.
- `openclaw/extensions/mattermost/src/channel.ts` supports Mattermost `send` / `react`, and the `send` path forwards `params.media` as `mediaUrl`; it does not forward `filePath`, `path`, `buffer`, `filename`, `mimeType`, or `attachments[]` into Mattermost upload handling.
- `openclaw/extensions/mattermost/src/mattermost/send.ts` and `client.ts` already contain a working Mattermost file upload flow when a `mediaUrl` reaches that layer, using `/files` and then `/posts` with `file_ids`.

Impact and severity

Affected: OpenClaw users delivering generated artifacts through the Mattermost plugin/bridge. Severity: High for file-delivery workflows. The assistant receives ok:true, but the intended file is not present in Mattermost. Frequency: Reproduced across four observed attachment payload shapes: attachments[].filePath, top-level filePath, attachments[].path, and buffer + filename. Consequence: Users can believe a generated document was delivered when Mattermost did not receive the intended file. The observed workaround is to bypass OpenClaw and upload through the Mattermost REST API directly.

Additional information

This is an OpenClaw Mattermost plugin/bridge issue, not a Mattermost server issue. Direct Mattermost /api/v4/files plus /api/v4/posts worked with the same bot token, same DM target, and same source markdown file.

Likely implementation issue based on observed code path: the generic OpenClaw message tool schema accepts multiple attachment-shaped fields, but the Mattermost send provider path only appears to forward params.media as mediaUrl. Attachment-shaped fields such as filePath, path, buffer, and attachments[] either need to be normalized into the Mattermost upload path or rejected with an explicit unsupported-field error.

Suggested fix: for Mattermost message(action="send"), define one canonical supported attachment shape and route it through Mattermost's native two-step flow: POST /api/v4/files followed by POST /api/v4/posts with file_ids. If non-canonical attachment fields remain unsupported, return an explicit error instead of ok:true.

Regression test idea: create a temporary markdown file, send it through the canonical Mattermost message-tool attachment shape, fetch the resulting post, and assert file_ids.length > 0, uploaded filename matches, and uploaded size matches the source file.