Downloading an attachment from Github issue in CI Pipeline #11832

I don't think there is a first-class GitHub API for issue attachments in the same way there is for release assets.

The way attachments work in GitHub docs today is mostly:

• the file is uploaded and referenced in the issue/comment body as an anonymized URL
• people who can view the issue can view the attachment

So for automation, the practical pattern is usually:

1. fetch the issue/comment body through the API
2. extract the attachment URL from the markdown/body
3. download that URL with credentials that can access the issue

But I don't think there is a dedicated stable "list attachments for this issue" API endpoint to rely on.

So if you need something more automation-friendly in CI, the safer alternatives are usually:

• store the file as a release asset
• store it in the repo/blob storage directly
• or include an explicit artifact URL from a system that exposes a real download API

Short answer: there is still no stable, supported API to download issue attachments in CI the way you can fetch release assets or repository contents. Attachments live on user-images.githubusercontent.com / github.com/user-attachments/ URLs embedded in the issue body, and those links are meant for browser sessions — not token-authenticated automation.

What does not work reliably

• gh issue view / Issues REST API — return the markdown body with attachment URLs, but not a durable download endpoint you can call with GITHUB_TOKEN alone.
• Scraping the attachment URL from the body — often fails in CI (403, redirect to login, or URL expiry) because the token is not scoped for user-content attachment delivery the same way your browser cookie is.
• gh api on undocumented attachment endpoints — brittle and not recommended for production pipelines.

This matches the limitation called out in cli/cli#11584 and community#162417.

Workarounds teams actually use

1. Do not use issue attachments for automation inputs. Ask contributors to upload files to a Release asset, artifact, or repo path (contents API) instead — those have first-class authenticated download URLs.
2. Manual / semi-manual bridge — a maintainer downloads the attachment locally and commits it or uploads to storage; CI consumes the stable copy.
3. Bot with elevated privileges — some orgs run an internal service using a PAT + browser-like session; high maintenance and usually not worth it vs. changing the workflow.
4. GHEC proxy / egress allowlist — if your blocker is network policy rather than API, you still need a stable URL + auth story, which attachments do not provide today.

Practical CI pattern

# Prefer inputs that CI can fetch with GITHUB_TOKEN
- uses: actions/checkout@v4
- run: gh release download "$TAG" --pattern 'report.zip'

If you must keep issue attachments for humans, add a label like needs-ci-input and a maintainer action that copies the file to a release or repo path before CI runs.

Enterprise note

On GitHub Enterprise Cloud, the same API gap applies — there is no separate “enterprise attachment API.” Your security team should treat attachment URLs as opaque, user-scoped links, not as integration points.

If GitHub adds attachment APIs in the future, gh issue download-attachment-style support would likely land in the CLI after the REST API exists — watch cli/cli issues rather than building on scraped URLs.