[Bug]: Slack file downloads save HTML instead of actual file content #18642
Description
Summary
Files attached in Slack (PDFs, images) are downloaded to /home/node/.openclaw/media/inbound/ but contain Slack's HTML sign-in/redirect page instead of the actual file content.
Environment
OpenClaw version: 2026.2.9
Deployment: Docker (self-hosted)
Slack integration: Socket mode
OS: Ubuntu on WSL2/Windows
Steps to reproduce
Send a PDF or image attachment in a Slack channel where OpenClaw is active
OpenClaw acknowledges the file and assigns a local path (e.g., /home/node/.openclaw/media/inbound/b270971f-....pdf)
Inspect the downloaded file
Expected behavior
File at the local path should contain the actual PDF/image binary content.
Actual behavior
Every file contains Slack's HTML redirect page (~53KB each). Running head -3 on any file shows:
<script>file command confirms they're HTML, not PDFs or images. All files in /home/node/.openclaw/media/inbound/ are affected — tested with 14 different uploads (PDFs and PNGs).
Root Cause (likely)
Slack's files.slack.com URLs require authentication via Authorization: Bearer xoxb-... header. The download pipeline appears to be fetching without the bot token, so Slack returns its sign-in page instead of the file content.
Impact
Cannot use the image vision tool on attachments
Cannot process PDF documents (e.g., tax/customs documents sent by partners)
Workaround: ask users to paste text content manually instead of attaching files
Suggested Fix
Pass the bot token in the Authorization header when downloading from files.slack.com:
curl -H "Authorization: Bearer $BOT_TOKEN" https://files.slack.com/files-pri/TXXXXXX-FXXXXXX/download/filename.pdf
OpenClaw version
2026.02.09
Operating system
Windows 11
Install method
docker
Logs, screenshots, and evidence
File listing showing all ~53KB (same size = same HTML page):
~/openclaw$ docker exec openclaw-openclaw-gateway-1 ls -la /home/node/.openclaw/media/inbound/
total 788
drwx------ 2 node node 4096 Feb 16 22:14 .
drwx------ 3 node node 4096 Feb 16 21:31 ..
-rw------- 1 node node 53654 Feb 16 21:33 3d1d81da-5628-4d96-8b73-a248c6fb23eb.pdf
-rw------- 1 node node 53431 Feb 16 21:40 46225499-8a9c-4d6a-80cb-173cea52ec6b.pdf
-rw------- 1 node node 53587 Feb 16 22:14 84e0cc2e-939e-4d0c-b895-21d8403a95da.png
-rw------- 1 node node 53440 Feb 16 22:06 8eace224-f0e4-4c92-bd04-0ec265c6162a.pdf
-rw------- 1 node node 53458 Feb 16 21:41 9ad99c6c-1f93-4579-bf6f-482e840081cd.pdf
-rw------- 1 node node 53457 Feb 16 22:12 a03b0fd4-5c45-4079-bdc8-bcccbab2bc4c.pdf
-rw------- 1 node node 53648 Feb 16 21:31 b270971f-71ce-415c-a80a-531ffe737e55.pdf
-rw------- 1 node node 53459 Feb 16 21:39 b501fb1b-ce93-4817-b153-e45f3de9e408.pdf
-rw------- 1 node node 53650 Feb 16 22:04 b6433c14-d8eb-491a-9ea0-892969cb4289.pdf
-rw------- 1 node node 53445 Feb 16 22:09 b7644d80-50b8-4d02-851b-7e8ed3d1d7bc.pdf
-rw------- 1 node node 53441 Feb 16 22:03 c4d32614-e708-49d7-9383-3044b1adfb1c.pdf
-rw------- 1 node node 53222 Feb 16 22:03 c7855ff7-c6b8-490f-af47-03df4a454ace.pdf
-rw------- 1 node node 53436 Feb 16 22:04 c8a15621-2f43-46e4-b64c-0835bfcd9d3f.pdf
-rw------- 1 node node 53673 Feb 16 22:08 e3e7266a-9bf2-412d-87a1-bae72ecd71dd.pdf
Head of a "PDF" showing HTML:
~/openclaw$ docker exec openclaw-openclaw-gateway-1 head -5 /home/node/.openclaw/media/inbound/b270971f-71ce-415c-a80a-531ffe737e55.pdf
<!DOCTYPE html><html lang="en-US" class="" data-primer data-cdn="https://a.slack-edge.com/"><head><script>
(function () {
var data;
Head of the "PNG" showing HTML:
~/openclaw$ docker exec openclaw-openclaw-gateway-1 head -5 /home/node/.openclaw/media/inbound/84e0cc2e-939e-4d0c-b895-21d8403a95da.png
<!DOCTYPE html><html lang="en-US" class="" data-primer data-cdn="https://a.slack-edge.com/"><head><script>
(function () {
var data;
OpenClaw [4:31 PM]
Tried opening the attached RFC file (b270971f-…pdf) from Slack, but it just loads the Slack sign-in page HTML — no actual PDF contents come through in this sandbox, so I can’t read the RFC value. If you can re-upload it as a direct PDF (or paste the RFC text), I can continue the workflow for order 1157425 right away.
Command failed. Output from convert /home/node/.openclaw/media/inbound/b270971f-71ce-415c-a80a-531ffe737e55.pdf /tmp/rfc_page.png:
OpenClaw [5:04 PM]
convert-im6.q16: attempt to perform an operation not allowed by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/426.
convert-im6.q16: no images defined `/tmp/rfc_page.png' @ error/convert.c/ConvertImageCommand/3229.
ImageMagick is blocking PDF reads due to its security policy.
~/openclaw$ docker exec openclaw-openclaw-gateway-1 cat /home/node/.openclaw/openclaw.json
{
"meta": {
"lastTouchedVersion": "2026.2.9",
"lastTouchedAt": "2026-02-14T19:40:03.786Z"
},
"wizard": {
"lastRunAt": "2026-02-12T01:30:20.370Z",
"lastRunVersion": "2026.2.9",
"lastRunCommand": "configure",
"lastRunMode": "local"
},
"agents": {
"defaults": {
"model": {
"primary": "openai/gpt-5.1-codex"
},
"models": {
"openai/gpt-5.1-codex": {
"alias": "GPT"
}
},
"compaction": {
"mode": "safeguard"
},
"maxConcurrent": 4,
"subagents": {
"maxConcurrent": 8
}
}
},
"messages": {
"ackReactionScope": "group-mentions"
},
"commands": {
"native": "auto",
"nativeSkills": "auto"
},
"channels": {
"slack": {
"mode": "socket",
"webhookPath": "/slack/events",
"botToken": "xoxb-x-x-x",
"appToken": "xapp-1-x-x-x",
"userTokenReadOnly": true,
"groupPolicy": "allowlist"
}
},
"gateway": {
"port": 18789,
"mode": "local",
"bind": "loopback",
"controlUi": {
"allowInsecureAuth": true
},
"auth": {
"mode": "token",
"token": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
},
"tailscale": {
"mode": "off",
"resetOnExit": false
}
},
"plugins": {
"entries": {
"slack": {
"enabled": true
}
}
}
}Impact and severity
Impact:
All Slack file attachments are unusable — 100% failure rate across all file types (PDF, PNG tested)
Vision tool (image) cannot function on any user-provided files
Business-critical documents (tax IDs, customs forms, shipping labels) sent by partners cannot be processed
Requires manual human intervention for every file attachment, defeating the purpose of autonomous operation
Workaround exists (ask sender to paste text) but adds friction and delays to time-sensitive shipping workflows
Severity: High
Not a crash or data loss, but completely blocks a core capability (file processing)
Affects every OpenClaw instance using Slack socket mode with file attachments
No user-side workaround possible — fix must be in the download pipeline
Likely a one-line fix (add Authorization header to file fetch request)
Additional information
No response