Inspect Releases with gh release view

Need to know which version of a tool just shipped, without opening a browser tab? gh release view tells you from the terminal, and this guide takes about ten minutes. You will inspect the latest release or an exact tag, name the repository explicitly, and pull out stable fields for a script. The examples use GitHub CLI 2.87.3, installed here as gh.

1. Check the installed command

Confirm the version and read the local help before you copy an example:

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

The command takes an optional tag, followed by output flags. The local help also lists the JSON fields available in this version, including tagName, name, publishedAt, assets and body.

Checkpoint: If your version is older or newer, compare its field list with these examples. Do not assume that a field introduced after your installed version will be available.

2. View the latest release

Run the command from a checked-out repository to use its GitHub repository as the target:

$ gh release view

With no tag argument, gh release view displays the latest release for the project. On the checked repository, the output begins like this:

title:  GitHub CLI 2.101.0
tag:    v2.101.0
draft:  false
prerelease: false

This is a moving target: a later release can change the result without changing your command. Fine for a quick human check, poor for a build that must refer to one known release.

Make the repository explicit when the current directory is ambiguous, or when you are writing a command for someone else:

$ gh release view --repo cli/cli
GitHub CLI 2.87.3

The --repo value uses [HOST/]OWNER/REPO. For GitHub.com, replace cli/cli with a real owner and repository, such as OWNER/REPO. The displayed release text can include its notes and other details, so do not parse this human-oriented output as if it were a fixed data format.

3. Inspect one exact tag

Pass a tag when you need a reproducible lookup. This read-only example checks the release tag used by the installed CLI release:

$ gh release view v2.87.3 --repo cli/cli
title:  GitHub CLI 2.87.3
tag:    v2.87.3
draft:  false
prerelease: false

The tag is a positional argument, not a flag. Quote it if it comes from a shell variable or another input source:

$ RELEASE_TAG='v2.87.3'
$ gh release view "$RELEASE_TAG" --repo cli/cli

Warning: If the tag does not identify a published release, the command exits non-zero and reports the lookup failure. Treat that as an input or repository problem first. Never silently fall back to the latest release, because that hides a broken pin.

4. Request selected JSON fields

Use --json when another command needs release data. Give it a comma-separated field list:

$ gh release view v2.87.3 --repo cli/cli --json tagName,name,publishedAt
{"name":"GitHub CLI 2.87.3","publishedAt":"2026-02-23T19:12:37Z","tagName":"v2.87.3"}

The key order is not a contract, so parse JSON by field name rather than matching the whole line. The values are release metadata. They do not prove that an asset has been downloaded or verified.

Keep the field list narrow. It cuts noise and makes a saved result easier to review. For a quick shell check, extract one value with --jq:

$ gh release view v2.87.3 --repo cli/cli --json tagName --jq '.tagName'
v2.87.3

Tip: The expression is evaluated against the JSON result. A typo in a field name or expression can produce an empty result or an error, so check the exit status in automation and test with a known tag first.

5. Format small reports with a template

--template formats the JSON data with a Go template. It suits output for a person rather than a JSON parser:

$ gh release view v2.87.3 --repo cli/cli --json tagName,name,publishedAt --template '{{.tagName}}: {{.name}} ({{.publishedAt}}){{"\n"}}'
v2.87.3: GitHub CLI 2.87.3 (2026-02-23T19:12:37Z)

Keep the template in single quotes so the shell does not expand its braces. It is applied to the JSON fields you requested. If a value can contain arbitrary text, prefer JSON output for a downstream program instead of building a delimiter-based format.

6. Open the release in a browser

Use --web when you want the release page rather than terminal output:

$ gh release view v2.87.3 --repo cli/cli --web

This asks the operating system to open the release in its browser. It can fail on a headless server, or over SSH without a graphical browser. In that case, use the normal output or copy the release URL from a JSON query:

$ gh release view v2.87.3 --repo cli/cli --json url --jq '.url'
https://github.com/cli/cli/releases/tag/v2.87.3

Warning: Treat a URL printed by the command as data to review before opening it, especially when someone else supplied the repository or host.

7. Make scripts fail clearly

For a script, pin the repository and tag, request only the fields you need, and stop on errors. This example checks that the returned tag agrees with the requested tag:

set -eu
REPO='cli/cli'
RELEASE_TAG='v2.87.3'
actual=$(gh release view "$RELEASE_TAG" --repo "$REPO" --json tagName --jq '.tagName')
if [ "$actual" != "$RELEASE_TAG" ]; then
    printf 'unexpected release tag: %s\n' "$actual" >&2
    exit 1
fi
printf 'checked release %s in %s\n' "$actual" "$REPO"

This verifies the lookup result, not the contents of release assets or the trustworthiness of release notes. If you need those guarantees, add separate asset download and verification steps with their own documented checks.

Common traps

Done means