Jira zips one issue. Satchel zips the whole search.

Need the files without an app? The guide to downloading all Jira attachments has a script you can run today and the traps that lose files.

Duplicate detection finds candidates, not proven duplicates. Jira exposes no content hash for an attachment, and proving two files identical would mean downloading both — for a whole project, every byte in it. Satchel therefore matches on filename and exact byte size, and that qualification travels with the number in the payload, so no screen can show you reclaimable bytes without the sentence explaining what they are based on. Two files with the same name and different sizes are not grouped; neither are two unrelated files that happen to be the same size.

Deletion is irreversible. Jira has no recycle bin for attachments. A file deleted through Satchel is gone from Jira: it comes back only from a copy you took beforehand, and Atlassian does not undo customer deletions from its own backups. Satchel checks every file with Jira, lists them, requires a typed confirmation and records every deletion, but it cannot undo one. Deletion ships switched off and, once on, is limited to Jira administrators unless they widen it.

One scope is broader than what the app does. Deleting an attachment needs Jira's classic write:jira-work scope, whose consent text mentions creating and editing issues, posting comments and deleting issues. Satchel does none of those, and it never uploads. It is the only classic Jira scope that includes deleting an attachment — the granular one that would say exactly that is still in Beta — and an automated test fails the build if any code path reaches a mutating call other than the single attachment delete.

Uploading attachments is deliberately not built. The write scope Satchel holds would allow it, but the only write call in its code is the attachment delete, and the interface has no path to upload.