Repository navigation
buzz upload file rejects PDFs/documents the relay accepts — agents can't attach files the desktop can #2963
Description
Thank you so much for releasing this beast in the wild! 🤗
Describe the bug
The CLI applies a client-side MIME allowlist that is stricter than the relay it uploads to, on the endpoint that exists to accept generic files. Files are rejected locally and never reach the server.
crates/buzz-cli/src/client.rs:1116 (upload_file):
if !ALLOWED_MIMES.contains(&mime.as_str()) {
return Err(CliError::Usage(format!("unsupported file type: {mime}")));
}ALLOWED_MIMES (client.rs:63) is image/jpeg, image/png, image/gif, image/webp, video/mp4.
But the same function uploads to PUT {relay}/upload (client.rs:1144) — the generic route, which the relay validates with validate_file_content() (crates/buzz-media/src/validation.rs:159) using a denylist (BLOCKED_FILE_MIME_TYPES: HTML/JS/SVG + executables). application/pdf is not blocked, and file_mime_to_ext() explicitly maps application/pdf → pdf and …spreadsheetml.sheet → xlsx.
So the server accepts these; the client refuses to send them.
To Reproduce
buzz upload file --file report.xlsx- →
{"error":"user_error","message":"unsupported file type: application/zip"}
(an.xlsxis a zip container, soinferreportsapplication/zip— a type the relay
accepts on this endpoint.) - Same for
.pdf,.docx,.csv. buzz messages send --file report.xlsxfails identically — same code path, and this is the
path agents use to attach anything.
Confirmed the server side by patching the check out locally and re-running: the same file
uploads and returns a normal {url, sha256, size} descriptor. Nothing server-side had to
change.
Expected behavior
The CLI should accept what the relay accepts. Either mirror BLOCKED_FILE_MIME_TYPES, or drop the pre-check and surface the server's 4xx — the server is the authority anyway, since it verifies magic bytes rather than a client-supplied type.
Why this matters
This is the file-attachment path for agents. Desktop already handles generic attachments (#2381 describes the composer as accepting "images, videos, PDFs, archives, and other supported files"), so an agent cannot attach a file that a human can attach to the same channel on the same relay.
Concretely: an agent that generates a spreadsheet or PDF report has no way to deliver it through Buzz.
Additional context
Two smaller issues in the same function:
- Size cap: non-video files are checked against
MAX_IMAGE_BYTES(50 MB,client.rs:1121). The relay has a separatemax_file_bytesfor the generic path, which the CLI has no notion of. - Error message:
unsupported file type: application/pdfstates the opposite of the truth for this relay, which makes the mismatch hard to diagnose.
If the relay ever exposes Blossom BUD-06 (HEAD /upload), asking the server for its
requirements would remove the duplicated policy entirely — the client would stop carrying a
second copy of a policy that only the server can enforce.
Environment
- CLI built from source at
9cc9652c; code references above are againstmain@a64cc71f, whereclient.rsis unchanged since that build - Relay: self-hosted,
main@ab3af828 - macOS 15 (arm64)
Activity
SteveSmart75 commentedon Aug 7, 2026
The error message is actively misleading — unsupported file type: application/pdf (or application/octet-stream in our case) states the type as the problem when it's really "not on this hardcoded allowlist."
Note there's a related open issue, #3083, proposing exactly the fix: expand ALLOWED_MIMES to match what the relay actually accepts.
maikunari commentedon Aug 7, 2026
Tracking note: #3060 (denylist mirror) is still open but conflicted/stale. Several later PRs target the same bug (e.g. #4298). Bug still reproduces on current main. No action needed from reporters beyond picking any landed fix once one merges.
mlamp commentedon Aug 27, 2026
On current
main, I found that thebuzzCLI rejects most file types before contacting the relay. A non-interactive agent that produces Markdown documents cannot attach them, while the desktop client uploads the same bytes successfully. This is a different case from the PDF and Office examples above.I measured two points that I have not seen stated in this thread.
The refusal is client-side
Point the CLI at a dead port and compare a refused type with an allowed type:
The PNG reaches the connection attempt. The Markdown file never opens a socket. I also confirmed this with a listener that received 0 bytes. The refusal is entirely client-side, so the relay is not consulted and cannot apply its own rules.
The effective allowlist
I probed ~50 types against a self-hosted relay. The entire accepted set was
png,jpg,gif,webp, andmp4. This effective allowlist is narrower than the issue title suggests.The full refused list, with MIME types correctly detected, was:
pdf,zip,gz,tar,7z,xz,zst,html,svg,sh,doc,rtf,wasm,ttf,sqlite,bmp,tiff,ico,avif,heif,jxl,psd,mov,mkv,webm,avi,mp3,flac,wav,ogg,opus,m4a,aac, andmidi.The issue is not limited to documents. Most ordinary image and audio formats are also refused.
Text files (
md,txt,csv, andjson) are refused asapplication/octet-streambecauseinferreturns nothing for them. That value is the fallback, not a special case. Allowingapplication/octet-streamwould therefore be the wrong fix. The set needs to be widened or inverted.Relay behavior and #4880
I uploaded the same Markdown with a raw Blossom
PUT /upload. The request used akind:24242auth event signed with the same key the CLI uses. It returned HTTP 200, and the file round-tripped byte-identically throughbuzz media get. The relay stored it asapplication/octet-stream.I also uploaded synthetic files with valid PNG magic bytes but invalid image payloads. The relay returned HTTP 422 with
invalid image data.The relay therefore re-validates the five types that the CLI permits and stores as-is the type that the CLI blocks. The client allowlist adds scrutiny where the server already has some and blocks the case the server handles most permissively.
These results support mirroring
BLOCKED_FILE_MIME_TYPESinstead of maintaining a second, stricter, unrelated client policy. Mirroring the relay's denylist keeps the CLI from drifting out of sync. That is the approach in #4880.aclark-avantiweb commentedon Nov 8, 2026
We're hitting this too, on a self-hosted relay (relay-v0.2.1). Our agents use
buzz messages send --fileto pass plans to each other, and the CLI refuses.md,.txt,.pdfand.ziplocally with "unsupported file type". We checked against an unreachable relay URL: the file never leaves the machine, while the same files upload fine from Buzz Desktop. For now our agents paste documents as message text instead.Any of #2431 or #7476 would fix it for us, together with #7324 so documents don't show up as broken images.