Install them only after reading the source, and re-check on every update. GitHub's documentation says extensions outside of GitHub and GitHub CLI are not certified by GitHub, and advises auditing an extension's source code before installing or updating it. An extension runs as you, with the access your logged in CLI session has.
Definition
GitHub CLI extensions are custom commands that anyone can create. An extension lives in a repository named with a gh- prefix. To be installable, the repository needs either an executable file at its root with the same name as the repository, or a set of precompiled binaries attached to a release. Extensions are installed locally and scoped to the user, so another machine or another user on the same machine does not get them.
You find extensions by browsing repositories with the gh-extension topic, which tells you something about quality control: a topic tag is self service.
What an extension can do
It is a program run by you. It can call the GitHub API with the token your CLI holds, read the local checkout, run git commands, and reach the network. If you have logged in with broad scopes, the extension can use them.
| Question | Why it matters |
|---|---|
| Interpreted script or precompiled binary? | A script is readable; a binary needs a build you can verify |
| Which repository owner? | Name collisions exist; the command only needs the repository name minus the prefix |
| What does the release contain? | Binaries attached to a release are not necessarily built from the tagged source |
| How does it update? | The upgrade command pulls new code, so an upgrade is a new trust decision |
One documented detail is worth knowing. If an extension with the same name is already installed, installing another with that name fails, and you must uninstall first. That prevents silent replacement through the install command, but it does not stop you from installing the wrong owner's repository in the first place, so check the owner.
Five steps before installing
- Read the repository. For a script, read the script. For a precompiled extension, look at the workflow that builds the release assets and confirm they come from the tagged commit.
- Check the owner and history. Established maintainers, a real issue tracker and a release cadence are good signs.
- Install with the full owner and repository name, then run
gh extension listto confirm what you have. - Treat
gh extension upgradeas an install. Read the diff for extensions that touch credentials or write data. Avoid running upgrade for all extensions blindly on a machine with broad scopes. - Reduce the token. Where you can, log in with the narrowest scopes for the work, and prefer fine-grained credentials to broad ones.
For teams
Decide whether extensions are allowed on developer machines at all. If yes, publish a short approved list with owner, version and the reason. If you build your own, create them as precompiled projects from the official scaffolding and ship them from your own organization so provenance is clear. Many teams find an internal extension is easier to defend than a dozen community ones.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what an extension's own dependencies add to your inventory.
Where Safeguard fits
For extensions you write, Safeguard's SBOM and dependency scanning and CLI help check the libraries you ship. The free scan at gold.safeguard.sh/scan can look at a repository.
Quick check
Are GitHub CLI extensions reviewed by GitHub?
GitHub's documentation says extensions outside of GitHub and GitHub CLI are not certified by GitHub and recommends auditing the source before installing or updating.
Are extensions shared across users on a machine?
No. They are installed locally and scoped to the user.
Sources
Last reviewed: 19 October 2026.
