openclaw - 💡(How to fix) Fix [Bug]: Slack MEDIA attachments are emitted as plain text instead of uploaded files [1 comments, 1 participants]

Summary

Valid MEDIA:/absolute/path/... directives in Slack replies are no longer being converted into uploaded Slack attachments. Instead, the MEDIA: line is effectively treated as normal message content, and no attachment appears in Slack.

This reproduces across agents and from canonical workspace paths, which points to the shared Slack attachment conversion layer rather than agent-specific path handling.

Environment

• OpenClaw on Linux
• Slack channel thread replies
• Reproduced with multiple agents:
  • chat agent
  • main agent control test
• Reproduced with canonical workspace paths:
  • ~/.openclaw/workspace/tmp/...
  • ~/.openclaw/workspace-main/tmp/...
• Reproduced with multiple file types:
  • PNG/image
  • .md file

Repro steps

1. Create a local file in an allowed/canonical workspace path, for example:
   • ~/.openclaw/workspace/tmp/slack-upload-test.md
   • ~/.openclaw/workspace-main/tmp/slack-upload-test.md
2. Send a Slack reply containing a valid standalone media directive, for example:

MEDIA:/home/<user>/.openclaw/workspace/tmp/slack-upload-test.md

1. Repeat with:
   • image files
   • markdown files
   • a control test where another agent creates the file/path and emits the MEDIA: line
2. Observe Slack result.

Expected behavior

OpenClaw should intercept the MEDIA: directive, upload the referenced file to Slack, and deliver it as an attachment/file in the thread.

Actual behavior

• No attachment appears in Slack
• In some cases the raw MEDIA:/absolute/path/... line survives into output rather than being converted into an upload
• No visible Slack upload occurs

What was ruled out

• bad MEDIA: syntax
• bad absolute path formatting
• agent-specific workspace/path handling
• chat-agent-only behavior
• simple local path-not-allowed rejection
• file-type-specific failure, since both image and .md tests failed

Why this points to the shared Slack conversion layer

• Reproduces across agents, including a main-agent control test
• Reproduces from canonical workspace paths
• Plain Slack replies still work
• The attachment conversion step appears to be skipped, so the problem looks upstream of Slack upload itself, in the logic that extracts/consumes MEDIA: directives for Slack delivery

Important distinction from a separate socket issue

There was also a separate Slack socket/reconnect problem on a newer build. After downgrading, socket instability was no longer the main symptom, but attachment delivery still failed.

So this attachment bug appears distinct from the socket bug.

Notes

I intentionally removed workspace-specific identifiers, channel IDs, and local usernames beyond generic path shapes. If useful, I can provide follow-up logs privately, but the key reproducible behavior is that valid MEDIA: directives survive as text or produce no attachment at all, even from canonical paths and across agents.