Read a GitHub Issue in the Shell with gh issue view

Someone pastes an issue number in chat, and gh issue view gets you the title, body and discussion without leaving the terminal. You will finish with a repeatable way to read an issue, pull in its comments, and extract fields as JSON or formatted text. The examples use GitHub CLI 2.87.3, installed here from package gh, and take about ten minutes if your login already works.

• You need: the gh command, network access to the GitHub host, and permission to view the repository.
• Read-only: it does not edit, close, label, lock or delete an issue.
• No elevated privileges. Do not add sudo to a GitHub CLI command unless your local shell setup specifically requires it.

1. Check the installed command

Confirm which executable your shell will run, then check its version:

$ command -v gh
/usr/bin/gh
$ gh --version
gh version 2.87.3 (2026-02-23)

Your path and version may differ. The version matters when you compare output from another host, because fields and formatting support can change between CLI releases.

2. View an issue in the current repository

From a checked-out repository, give gh issue view an issue number:

$ gh issue view 123

It shows the issue title, body and other information. Replace 123 with the real number. If you already have a URL, use that instead:

$ gh issue view https://github.com/OWNER/REPOSITORY/issues/123

3. Select a repository explicitly

The inherited --repo option accepts [HOST/]OWNER/REPO. It avoids the classic mistake where the current directory points at a fork or an unrelated checkout:

$ gh issue view 123 --repo OWNER/REPOSITORY

For GitHub Enterprise, include the host:

$ gh issue view 123 --repo github.example.com/OWNER/REPOSITORY

4. Include the discussion

Comments are left out of the normal display unless you ask for them:

$ gh issue view 123 --repo OWNER/REPOSITORY --comments

That suits a human review, but the display is meant for people, so it is awkward in a script. For a machine-readable record, request JSON fields instead.

A successful lookup does not mean you have the whole discussion. You only get it with --comments or by selecting the comments field in JSON.

5. Extract stable JSON fields

Use --json with a comma-separated field list when another command needs structured data. The installed command documents fields including number, title, body, state, author, labels, assignees, createdAt, updatedAt, url and comments:

$ gh issue view 123 \
    --repo OWNER/REPOSITORY \
    --json number,title,state,author,url

The output is JSON, so feed it to a JSON-aware tool instead of parsing the human display. This prints only the URL and title:

$ gh issue view 123 --repo OWNER/REPOSITORY \
    --json number,title,url \
    --jq '.url + " " + .title'

Here --jq filters the JSON with a jq expression. Keep the expression quoted so the shell does not expand punctuation before gh sees it.

6. Format a small report with a template

Use --template for controlled text output when you do not need a separate JSON processor:

$ gh issue view 123 --repo OWNER/REPOSITORY \
    --json number,title,state,updatedAt \
    --template 'Issue #{{.number}}: {{.title}} ({{.state}}, updated {{.updatedAt}})\n'

Templates use Go template syntax, and they only see fields requested with --json. Add a field to that list before you refer to it. For nested values such as an author, run a small JSON request first and look at the shape rather than guessing.

7. Handle authentication and failures

If the command reports an authentication problem, inspect the login state without printing a token:

$ gh auth status

Follow your organisation's login policy if authentication is missing. Do not paste an access token into shell history, an issue body or a script.

A repository access error is not the same as an invalid issue number. Verify --repo, the host and your account's permission before changing anything.

In a script, keep the exit status and stop on failure instead of emitting an empty report:

set -eu
issue_json=$(gh issue view 123 --repo OWNER/REPOSITORY \
    --json number,title,state,url)
printf '%s\n' "$issue_json"

This captures the JSON only after a successful lookup. It does not retry network failures or hide permission errors. Add retry logic only when you can tell a temporary transport failure from a permanent access or repository error.

8. Avoid the common traps

• Numbers are per repository. An issue number is read in the selected repository, so a familiar number from another project is not a safe identifier.
• The default display is for people. Use --json, --jq or --template when output goes into a script.
• --comments is display only. It changes the human display but is no substitute for selecting the comments JSON field in a structured workflow.
• --web opens a browser. It opens the issue in a browser instead of the terminal, so it is interactive and no good for a headless job.
• Root does not help. Local root privileges do not grant repository access, so do not use an elevated shell to fix a GitHub permission problem.