Home / Alt manpages / gh-extension-browse(1)

  • gh-extension-browse(1)
  • User command
  • linux

Browse GitHub CLI Extensions Without Losing Your Place

Run gh extension browse and your terminal becomes a full-screen picker for every extension gh knows, and quitting is not obvious at first. This guide covers the interface, how to vet an extension before you install it, and how to get out again. The examples use GitHub CLI 2.87.3 on this machine, while the installed Debian package is gh 2.45.0-1ubuntu0.3+esm3, so check your own version before assuming the screen matches.

The route

Jump straight to the step you need, or tick off Done means at the end.

Allow about fifteen minutes. You need a terminal, the gh command, and a GitHub CLI authentication setup if the interface asks GitHub for data. None of this needs elevated privileges, and it only changes your extension set if you deliberately confirm an add or remove inside the interface.

1. Confirm what you are actually running

Check the executable and its help before the interface takes over the screen:

$ command -v gh
/usr/local/bin/gh
$ gh --version
gh version 2.87.3 (2026-02-23)
$ gh extension browse --help
Usage: gh extension browse [flags]
  • --debug logs to a path matching /tmp/extBrowse-*, useful when something behaves oddly.
  • -s / --single-column renders the whole interface as one text column instead of a grid.

Checkpoint

If gh --version reports a different build to the one here, keep that fact with your notes. Package upgrades can change the interface and which commands it offers.

2. Pick a display mode that suits your terminal

Open the normal browser when your terminal is wide enough:

$ gh extension browse

The manpage recommends a terminal wider than 100 columns. This is not a command that prints a report and hands control straight back: it takes over the terminal and stays interactive until you quit it.

If you use a screen reader, high zoom, or a narrow terminal, start single-column instead:

$ gh extension browse --single-column

That only changes the presentation, not what you can do inside it. Once you are in, press ? for the control help and q to quit. Do not guess keys from a different terminal app: use the help this version actually shows you.

3. Treat installation as a trust decision, not a click

Browsing is fine for discovery, but every extension is a repository that adds commands to gh. GitHub does not verify, sign or endorse any of them. Before you approve an install:

  • Search from the shell instead of the picker when you want results you can save or compare: 
    $ gh ext search ISSUE_TERM
    Replace ISSUE_TERM with a real term, such as review. With no query at all, gh ext search just lists the first 30 extensions by star count, and a high star count is not a security verdict.
  • Open the repository before you touch anything: 
    $ gh repo view OWNER/REPOSITORY
    Replace both placeholders with the exact repository you found. Check the publisher, the release process, the permissions it asks for, and how recently it has been maintained. Stop if the identity of the repository is unclear.

4. Install only once the review is done

Warning

Installing an extension downloads and runs code from its publisher the moment you invoke it, and it changes your local extension set. Confirm the repository name and, where reproducibility matters, pin a reviewed release or commit:

$ gh ext install OWNER/REPOSITORY --pin REVIEWED_TAG_OR_COMMIT

--pin takes a tag for binary extensions or a commit reference for script extensions. Replace REVIEWED_TAG_OR_COMMIT with something you have actually checked, not a guess. Skip --pin and you get the latest version, which is convenient but not repeatable.

Confirm it landed:

$ gh ext list

Tip

Do not rely on a particular table layout here, only on the extension name being present.

5. Remove an extension without losing the way back

Warning

Removal changes your local installation and can break scripts or aliases that call the extension. Write down the repository and pinned reference first if you might want it back.

Replace EXTENSION_NAME with the installed extension name, normally the part after gh-:

$ gh ext remove EXTENSION_NAME

Confirm the result:

$ gh ext list

Changed your mind? Reinstall from the repository and reference you recorded:

$ gh ext install OWNER/REPOSITORY --pin REVIEWED_TAG_OR_COMMIT

Recovery

That restores the same source, not a guaranteed byte-for-byte backup. A repository can remove a release or change its build process, so keep your own record of what you actually installed.

Common traps

  • Guessing keys from another tool. Press ? inside the interface for this version's actual controls.
  • Trusting a high star count. Popularity is not a safety check; read the repository yourself.
  • Cleaning up debug logs with a wildcard. If diagnostics matter, run: 
    $ gh extension browse --debug
    then read and remove the specific file rather than sweeping the directory: 
    $ ls -l /tmp/extBrowse-*
$ rm -- /tmp/extBrowse-EXACT_FILE_NAME
    Replace EXACT_FILE_NAME with the path you actually found, since several debug sessions can leave several files, and those logs may contain repository names or other session details worth treating as sensitive.
  • Assuming a fetch failure means broken extensions. Check authentication and network access separately before installing an unreviewed alternative as a workaround.

Done means

  • Confirmed executable and version: you know which gh ran the browser.
  • Comfortable in the interface: you can open it, use ? for controls, and quit with q.
  • Picked the right display mode: you know when --single-column is clearer.
  • Reviewed before installing: you checked the repository, not just the star count.
  • Pinned where it mattered: you used a reviewed tag or commit for repeatability.
  • Can undo cleanly: you can list, remove and reinstall an extension without guessing its identity.