Download GitHub Release Assets Safely with gh

You will download a GitHub release asset into a directory you choose, either by naming an exact release or by selecting matching files from the latest release. Allow about ten minutes for a first download, including a quick file and checksum check. The examples use the installed GitHub CLI version 2.87.3 and the command documented by gh-release-download(1).

1. Check the command and authentication

Install GitHub CLI through your normal distribution or organisation process, then check the executable before downloading anything:

$ gh --version
gh version 2.87.3 (2026-02-23)
$ gh release download --help

The download command needs access to the repository's release. Public releases normally work without a sign-in, while private repositories require an authenticated account with suitable access. Check the current account without changing anything:

$ gh auth status

If that reports that no account is available, sign in with gh auth login and follow your organisation's policy. Do not paste a personal access token into a shell command or save it in a script.

2. Download every asset from a named release

Use an explicit tag when reproducibility matters. This example downloads all assets from version v1.2.3 in the repository OWNER/REPO:

$ mkdir -p /tmp/release-assets
$ gh release download v1.2.3 \
    --repo OWNER/REPO \
    --dir /tmp/release-assets

The command writes the assets into the directory and preserves their release filenames. List the result before using it:

$ find /tmp/release-assets -maxdepth 1 -type f -printf '%f\n'
example-linux-amd64.tar.gz
example-linux-amd64.tar.gz.sha256

--repo accepts [HOST/]OWNER/REPO, so it also works with a GitHub Enterprise host. If you omit the repository, gh uses the repository associated with the current working directory when it can identify one.

3. Select only the assets you need

Use --pattern with a glob when a release contains several platforms or formats. Quote the pattern so your shell passes it to gh unchanged:

$ mkdir -p /tmp/release-assets
$ gh release download v1.2.3 \
    --repo OWNER/REPO \
    --pattern '*linux-amd64*' \
    --dir /tmp/release-assets

Pass -p more than once for separate patterns:

$ gh release download v1.2.3 \
    --repo OWNER/REPO \
    -p '*.deb' \
    -p '*.deb.sha256' \
    --dir /tmp/release-assets

Check the names after the command. A pattern that matches nothing is a selection problem, not evidence that the release has no assets. Inspect the release page or use gh release view v1.2.3 --repo OWNER/REPO to confirm the published names.

4. Download from the latest release deliberately

With no tag, the command targets the repository's latest release. The installed command requires either --pattern or --archive in this mode, which prevents an unqualified download of every latest asset:

$ mkdir -p /tmp/latest-assets
$ gh release download \
    --repo OWNER/REPO \
    --pattern '*linux-amd64*' \
    --dir /tmp/latest-assets

Latest is a moving reference. Record the selected tag if the downloaded file will be deployed or used in a build. For a repeatable process, replace the omitted tag with the exact tag shown by the release listing.

5. Download the source archive

Use --archive when you want GitHub's source archive rather than an uploaded release asset. The accepted formats in the installed manual are zip and tar.gz:

$ mkdir -p /tmp/source-archive
$ gh release download v1.2.3 \
    --repo OWNER/REPO \
    --archive tar.gz \
    --dir /tmp/source-archive
$ find /tmp/source-archive -maxdepth 1 -type f -printf '%f\n'

Use an explicit tag for a source archive you need to rebuild later. An archive is not necessarily the same thing as an uploaded binary asset, and it does not by itself prove that a binary was built from that source.

6. Protect existing files

The default destination is the current directory. Set --dir explicitly in scripts so a changed working directory does not scatter downloads into an unrelated location. Existing files are a safety boundary:

$ gh release download v1.2.3 \
    --repo OWNER/REPO \
    --pattern '*.tar.gz' \
    --dir /tmp/release-assets \
    --skip-existing

--skip-existing leaves files with the same name alone. Use it when an interrupted or repeated job should keep an existing local copy. Use --clobber only when replacing same-named files is intentional and you have checked the destination first:

$ find /tmp/release-assets -maxdepth 1 -type f -printf '%p\n'
$ gh release download v1.2.3 --repo OWNER/REPO --pattern '*.tar.gz' \
    --dir /tmp/release-assets --clobber

Overwriting is irreversible if the old file has no backup. Do not combine --clobber with a broad pattern in a directory containing important files unless that replacement is the intended change.

7. Verify the downloaded file before using it

A successful download means that GitHub CLI wrote the selected response. It does not establish that the file is suitable for execution or deployment. Inspect its type and, when the release publishes a checksum, verify it:

$ file /tmp/release-assets/example-linux-amd64.tar.gz
$ sha256sum -c /tmp/release-assets/example-linux-amd64.tar.gz.sha256

Checksum files vary in format and filename. Read the file before running the check, and confirm that the referenced filename is the one you downloaded. If the checksum fails, stop. Remove the suspect file from the temporary directory and download again after checking the repository and tag, rather than extracting or executing it.

Do not use sudo for these downloads. Writing to /tmp or to a user-owned working directory should not need elevated privileges. Use elevated privileges only for a separate, deliberate installation step after verification, and review that step as a change to the system.