feat: support non-image binary file attachments inbound (PDFs, office docs, video) on Slack/Discord

[ShinyChang]

Description

Inbound non-image, non-audio, non-text-extension files (PDFs, .docx, .xlsx, .pptx, video, archives, etc.) are silently dropped by the Slack and Discord adapters. The agent receives the user's text prompt with no indication that an attachment was even sent.

Current adapter routing on main (after #291):

• image/* → resize + base64 → ContentBlock::Image ✅
• audio/* → STT transcript → ContentBlock::Text ✅
• text-extension files → inline content → ContentBlock::Text ✅
• everything else → silently dropped ❌

This was previously raised in #254 ("support non-image file attachments (download to disk)"), where maintainers laid out a hybrid design and a security checklist. That issue was closed with Close in favor of #652, but #652 is the outbound images/files docs PR (docs: add sendimages.md and sendfiles.md), which doesn't address inbound binary handling. The inbound gap remains in main as of v0.8.3-beta.2.

Requesting we revive the design from #254 and land a download_to_disk fallback for binary attachments.

Use Case

Production deployment running openab-claude as a Slack bot for an internal team. Users routinely drop .xlsx reports, .docx drafts, .pdf documents, and .mp4 screen recordings into bot threads.

The bot has Anthropic's official document skills (docx, pdf, pptx, xlsx) plus a video-analysis skill mounted, with their runtime dependencies (LibreOffice, pandoc, Tesseract, ffmpeg) installed in the container. The skills can process every one of these formats — but openab never tells the agent the file exists, so the skills never trigger.

Concrete user-facing failure: user uploads report.xlsx and asks @bot summarize this. Bot responds with something like "I don't see any attachment in this thread." This is misleading and forces users to manually paste content as text or share via out-of-band channels.

This isn't a niche workflow, drag-and-drop file upload is the default mental model for Slack/Discord users. Every non-image attachment hitting an openab-driven bot today silently goes nowhere.

Proposed Solution

Implement the design from #254: a download_to_disk fallback in src/media.rs, used when a file isn't audio / inline-text / image. Returns a ContentBlock::Text with a structured "[Attachment received]" header pointing to the on-disk path, so agents with file-reading tools can pick it up.

Reference implementation (POC)

A working POC has been running in production for several days. Branch:

https://github.com/ShinyChang/openab/tree/feat/download-to-disk-attachments

Diff: main...ShinyChang:openab:feat/download-to-disk-attachments

Touches three files:

• src/media.rs — adds download_to_disk() + sanitize_path_component()
• src/slack.rs — replaces image-only fallback with image-OR-disk (bucket = ts)
• src/discord.rs — same shape (bucket = msg.id)

Files land at ${OPENAB_ATTACHMENTS_DIR:-/tmp/openab-attachments}/<bucket_id>/<filename>. Tested in production with .xlsx / .pdf / .mp4 attachments via Slack — agent receives the path block, triggers the matching skill, processes the file end-to-end.

Known gaps vs the #254 security checklist

The POC ships fast but does not yet meet the bar maintainers proposed in #254:

• Filename sanitization (path separators, null bytes, control chars)
• Path containment check after resolve (prevent symlink / .. escape)
• SSRF guard on download URL (block private IP ranges)
• Cleanup after stream_prompt returns (collect PathBufs, remove_dir_all)
• <<<EXTERNAL_UNTRUSTED_CONTENT>>> markers around file path block
• Config-driven ([<adapter>.attachments] TOML section vs current env-var only)
• 200 MB hardcoded cap → should be configurable

Hybrid (small-text inline vs disk-fallback) is already covered by the existing is_text_file branch landing first in the routing chain, so no new logic needed there.

[chaodu-agent]

Maintainer feedback: prefer URL pass-through over download-to-disk

Thanks for the detailed write-up and the working POC, @ShinyChang.

We agree the silent-drop gap is real and should be fixed. However, we'd like to go with a simpler approach than download-to-disk:

Pass-through the attachment URL as a text content block

Instead of openab downloading files to disk, we pass the CDN URL + metadata directly to the agent:

[Attached file: report.xlsx (application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, 245 KB)]
URL: https://cdn.discordapp.com/attachments/.../report.xlsx?ex=...

The agent (Claude Code, Gemini CLI, Codex, etc.) can then decide whether to fetch the file using its own tools (curl, fetch, Read, etc.).

Why this approach

	download-to-disk (POC)	URL pass-through
Complexity	~130 lines, temp dir, cleanup logic	~10 lines, stateless
Security surface	Path traversal, SSRF, symlink, disk exhaustion	None — openab never touches the file
Cleanup	Must track and delete temp files	Nothing to clean up
Agent compatibility	Requires file-reading tool	Requires HTTP fetch tool (all modern coding agents have this)
Latency	Double download (CDN→openab→disk→agent)	Single download (CDN→agent)

CDN URL expiry

Discord CDN URLs are signed and expire (~24h), but prompt processing completes in seconds, so this is not a practical concern.

What about the existing text-file inline path?

The current is_text_file branch already handles small text files by inlining content. That stays as-is. This change only affects the else branch (binary files that are currently silently dropped).

---

If you'd like to submit a PR with this approach, the change would be minimal — in the fallback branch of src/discord.rs and src/slack.rs, emit a ContentBlock::Text with the attachment metadata + URL instead of skipping. No filesystem interaction needed.

Let us know if you have questions or want to pick this up!

[ShinyChang]

@chaodu-agent thanks for the considered response. I want to push back on one point — the URL pass-through approach has a structural blocker on Slack that the table glosses over, plus a couple of practical issues across both adapters.

Slack files require Bearer auth — they're not a public CDN

files.slack.com URLs return 403/404 without Authorization: Bearer <bot_token>. You can see this in the existing slack.rs paths: both download_and_encode_image and download_and_read_text_file are called with Some(bot_token) for exactly this reason.

For URL pass-through to work on Slack, we'd need one of:

1. Plumb the bot token into the agent's prompt context. This means whatever the agent can be tricked into doing via prompt injection (post to allow-listed channels, read history of joined channels) becomes reachable. Significant security regression.
2. Switch to permalink_public. Not all uploads expose this field, and toggling it makes attachments to private channels publicly accessible to anyone with the URL. Also a regression.

Discord is different — signed CDN URLs work without auth. There the table holds. So Slack and Discord aren't symmetrical for this design.

Other practical issues

Local-path expectation in downstream tooling. A lot of file-processing tooling agents commonly reach for (office-doc parsers, PDF readers, video-frame extractors) takes a local path, not a URL. URL pass-through forces the agent to do curl -o /tmp/foo.xlsx <url> before doing anything useful. The disk interaction doesn't disappear, it moves into the agent — which means the agent now owns path management and cleanup, in a constrained tmpfs. Net: same complexity, different layer.

CDN URL expiry. "Prompt processing completes in seconds" holds for short prompts, but multi-turn sessions running larger workflows can run 10–30 minutes. With session TTL and session/load resume, an agent picking up a paused session can hit an expired URL. Discord's 24h is probably fine; Slack signed URLs are tighter.

Loss of size cap. The current 200 MB pre-check in openab disappears with pass-through. Nothing prevents the agent from curl-ing a 5 GB file against the same container.

Observability. openab's logs currently show attachment saved to disk size=X. With pass-through, openab has no signal on whether/when/how much the agent actually fetched.

Where the proposal is correct

• ~10 lines vs ~130 lines — genuinely smaller diff.
• Path traversal / SSRF / cleanup attack surface really does go away.
• Stateless / no orphaned files — true.
• For Discord specifically: no double-download.

Counter-proposal: per-adapter split

Rather than one approach for both:

• Discord → URL pass-through. Public signed CDN, your simplification points all hold.
• Slack → download_to_disk (or equivalent server-side fetch). The Bearer-auth requirement is a Slack API constraint, not a design choice we can engineer around without regressing security.

This keeps the adapters honest about what each platform actually offers. The ~130 line cost is paid only on the adapter that demands it.

Longer-term: gateway as the credential-aware fetch boundary

Reading the Custom Gateway ADR, the principle "OAB remains outbound-only and platform-agnostic — all inbound webhook handling and platform credentials live in the gateway" suggests the architecturally clean home for this is eventually the gateway, not the adapters. A gateway that already holds the platform credentials can fetch on the agent's behalf and hand back a normalized reference (path, signed internal URL, or inline block) — same shape across every platform, OAB itself stays stateless. Slack and Discord aren't routed through the gateway today, so that's a much larger move than #738 should try to land, but it might be worth flagging as a direction the per-adapter split here is consistent with rather than against.

If the per-adapter split for #738 itself is acceptable, I can split the existing PoC into two PRs (Discord pass-through standalone, Slack download-to-disk with the security checklist from #254 hardened to your bar). Happy to also be talked out of this if there's a Slack auth angle I'm missing.