Disabling extension download using github cli #13622

gh extensions should be treated as arbitrary local executables, not as reviewed/managed GitHub features. The CLI docs state that extensions are not verified, signed, or endorsed by GitHub, and gh extension install may either download release binaries or clone a repo and execute the matching gh-* file. (cli.github.com)

Not aware of an Enterprise Cloud policy knob that centrally disables gh extension install. The documented environment controls cover things like update notifications and config location, not an extension allow/deny policy. (cli.github.com)

For enterprise rollout, the usual control point is outside gh: distribute gh through MDM/package management, block execution from the user extension directory with endpoint controls such as WDAC/AppLocker/Jamf/EDR, restrict egress or release downloads to unapproved repos, and maintain an internal allowlist or mirror of approved extensions. If extensions are allowed, pin approved installs with --pin and run them through the same review/provenance process as any other developer workstation tool.

If my answer solved your problem, please mark it as answered the question — I'm here to help, and honestly I'm also collecting Galaxy Brain badges along the way 😆

For GitHub Enterprise Cloud, there isn’t a single global “disable gh extension install for all users” switch in gh itself — extensions install from git remotes the user can read.

Practical controls IT teams use:

1. Network allowlist — Block outbound git/https to arbitrary GitHub repos from managed machines; allow only approved hosts.
2. Policy / MDM — Ship a wrapper or remove gh extension subcommands via managed config; document approved extensions only.
3. Org security — Restrict which repos users can clone; private/internal only reduces random public extension installs.
4. Enterprise managed users / device posture — Keep CLI on managed devices with egress controls.

Feature request path: open a discussion/issue on cli/cli asking for an enterprise policy flag (e.g. disable extension install via gh config enterprise policy). Worth +1’ing if it doesn’t exist yet for your compliance story.

If you share whether devices are MDM-managed, I can suggest a tighter concrete policy.

For enterprise deployments, treat gh extension install like any other unaudited package manager — assume extensions are untrusted unless you vet them.

What GitHub does not provide today

There is no built-in enterprise allowlist/blocklist for gh extension install. Extensions are Go plugins fetched from GitHub repos and executed locally.

Practical risk controls

1. Document an approved extension list — only install extensions your security team has reviewed (repo + release tag pinned).

2. Pin installs to a version/tag

   gh extension install owner/repo --pin v1.2.3

3. Block via endpoint policy (MDM / proxy)

   • Restrict outbound GitHub API for unapproved users
   • Use corporate proxy TLS inspection for github.com asset downloads

4. Least-privilege tokens

   • Developers use gh auth login with fine-grained PATs scoped to required repos only
   • CI uses dedicated machine users, not personal admin tokens

5. Audit locally

   gh extension list
   ls "$(gh extension dir)"

   Include extension directory in endpoint security scans.

6. Prefer built-in gh commands over extensions for regulated workflows — wrap approved operations in internal CLIs you control.

For GHE Cloud admins

• Use GitHub Apps or internal automation for approved workflows instead of arbitrary extensions
• Enforce 2FA + SSO for all developers
• Monitor audit log for unusual API patterns

Community pattern

Many enterprises run an internal "approved tools" doc and block gh extension install in onboarding scripts, providing a curated internal extension repo instead.

There is an open feature request for enterprise extension governance — worth upvoting if this is a blocker for your rollout.

You are right to treat gh extension install as installing unvetted code from arbitrary GitHub repositories. The CLI team does not centrally review extensions; each extension is a separate repo that builds a local binary and hooks into gh.

What GitHub / gh does not provide today

• No official extension allowlist / blocklist in GitHub Enterprise settings.
• No code signing or malware scanning before install.
• No sandbox — extensions run with the same privileges as the user running gh (including access to GH_TOKEN / keyring credentials).

gh extension browse surfaces community extensions; installing is equivalent to trusting that repo's maintainers.

Risk controls enterprises use in practice

Operational recommendation

1. Publish an internal approved-extensions list (JSON + install script).
2. Train developers: no extensions on production-access machines unless on the list.
3. Prefer native gh commands / GitHub Actions / internal tools over extensions for regulated workflows.
4. Log and review — treat a new extension like installing a new npm global binary from an unknown publisher.

Feature gap

An enterprise-friendly gh extension policy (org-level allowlist synced from GitHub settings) would address this cleanly; until then, governance is process + endpoint controls, not a switch in GHEC admin.

Happy to share a sample allowlist manifest format if useful for your security review packet.

I'd suggest the following approach:

1. Check if you're using the latest version - many issues are resolved in recent releases.
2. Review the official documentation for any breaking changes.
3. Try clearing your cache/node_modules and reinstalling dependencies.

If none of these work, providing a minimal reproduction repo would help the maintainers diagnose the issue faster.