Support downloading attachments from issues/PRs

[drogers0]

Idea

gh-image currently only handles the upload half of the attachment problem. The download half has no solution anywhere in the ecosystem: there is no way to fetch a user-attachments file from a private repo programmatically.

Since gh-image already solves the browser-session problem for uploads, it is well positioned to do the same for downloads — e.g.:

gh image download <user-attachments-url> [-o path]
gh image download --issue 42 --repo owner/repo    # pull every attachment off an issue

The session resolution order would be identical to upload (--token → GH_SESSION_TOKEN → browser cookie), so no new credential surface is introduced.

Why this is worth doing

This is a genuine, well-documented ecosystem gap. user-attachments links on private and internal repos require a browser session — fine-grained PATs, classic PATs, OAuth apps, and GitHub App tokens all return 404:

• cli/cli#9046 — "Download attachment/file from an issue/pr" (open)
• github/gh-aw#21242 — "Enable agentic workflows to access issue/PR file attachments" (open; GitHub's own agentic-workflows project hitting the same wall)
• community#162417 — "Unable to download attached file to a GitHub Issue" (answered: "These links need a browser session, so API requests won't work"; the suggested workarounds are headless Puppeteer or "don't use attachments")
• community#54551 — "More secure private attachments - GA", the change that made this session-only in the first place

Open questions

• Should this be gh image download, or a separate verb? Downloading isn't really "image" anymore.
• Bulk mode: worth resolving attachments straight off an issue/PR body, or keep it URL-in / file-out?
• Interaction with the security work in Harden SKILL.md against automated security scan findings #39 — this reads remote content, so any prompt-injection boundary guidance in SKILL.md needs to cover downloaded content too, not just uploads.

Not scheduled — filing so the idea isn't lost.

[drogers0]

Implementation plan

Attached: 42_download_attachments_PLAN.md

On the premise above

The framing in this issue is more absolute than it should be. The way GitHub handles attachment downloads is hard to pin down across all cases, and a broad user PAT or OAuth token is frequently a workable alternative.

But those require setup, and are not always an option — which is what leaves this feature with value. Two concrete gaps it closes regardless of credential:

• curl -O on an attachment URL writes 0 bytes and exits 0. Without -L it saves the empty redirect body and reports success. The obvious invocation fails silently.
• curl -LO on an /assets/ URL produces an extensionless uuid. Those URLs carry no Content-Disposition; only the redirect reveals the type, so a shell cannot work the filename out.

Shape

One primitive — fetch a user-attachments URL you already have:

gh image download [--output <file>|-] [--output-dir <dir>] [--no-clobber]
                  [--token <value>] <url>...

Auth: the session token, always — same credential and precedence as upload (--token → GH_SESSION_TOKEN → browser), reusing the existing resolveSessionCookie unchanged. A deliberate trade of least-privilege for simplicity: one credential, one story, no negotiation machinery. Download invokes gh zero times.

Two HTTP calls. A GET on the attachment URL returns 302 to a presigned URL; the presigned URL is then fetched with no credentials at all — sending Authorization to the S3 host returns 400. Neither client follows redirects; the redirect is classified explicitly, so an SSO or error page can never be written to disk as an attachment.

Output follows curl's conventions: derived name by default, --output-dir for a directory, --output <file> for an exact path, --output - for stdout, overwrite by default with --no-clobber to suffix name.1.

Filenames come from the URL — the <name> segment for /files/, the uuid plus the extension from the redirect for /assets/. No remote header ever names a file.

Answers to the open questions

1. gh image download, in this binary — the tool already handles non-image attachments (Support uploading non-image files (PDF, zip, etc.) #24), so "image" is already broader than its name.
2. URL-in / file-out only. Bulk --issue scanning was cut: the caller who ran gh issue view is already looking at both the URL and its label, and a grep | xargs pipe reproduces the rest. Better to be a good xargs citizen than to reimplement discovery.
3. Harden SKILL.md against automated security scan findings #39 no longer intersects. Not scanning issue text means never fetching a URL that someone else's comment chose — the confused-deputy path disappears with the feature rather than needing a policy.

Related

The /login redirect this plan detects is the same class of problem as #41's sign-in-page detection — an expired session reported as something else. The two should word their errors alike.

Also verified while probing: a /files/ URL's filename is server-validated (a tampered name returns 404), and GitHub sanitizes uploaded filenames (paren (1) test.txt → paren.1.test.txt).

Not scheduling this — the plan is here so the work isn't lost.