GitHub CLI Linux package key expires September 5

GitHub’s current PGP key for the Linux package repositories used by GitHub CLI (gh) expires on Saturday, September 5, 2026. The CLI itself is not being retired, but older repository configurations can stop verifying package metadata or new packages after the key rollover.

The deadline matters for teams that installed gh through GitHub’s official APT or RPM repositories before April 8 and have not refreshed their setup since. GitHub published a replacement keyring in April containing both the old and new keys. Re-running the current distro-specific installation steps updates the trust configuration.

Who needs to act on the GitHub CLI key rollover

The affected paths are Linux installations that use GitHub’s APT or RPM repositories, including apt, yum, dnf, and zypper configurations that still contain only the expiring key. This includes developer machines, CI runners, container base images, and long-lived servers assembled from older bootstrap scripts.

The failure is likely to appear during a future repository update rather than when an existing binary starts. A machine can continue to run gh --version while its package manager is no longer able to authenticate repository metadata. That distinction makes stale images and unattended build scripts easy to miss.

Refresh the keyring before the September 5 deadline

Use GitHub’s current Linux installation instructions to refresh the repository setup for the distribution in question. Do not copy a key from an old internal script. After updating, verify that the local keyring contains the replacement fingerprint as well as the historical key where the installation guide expects both.

For fleet environments, update the image build and provisioning path, then test the package-manager metadata operation in a clean environment. A one-off repair on a workstation will not protect a CI image that still installs the old key on every rebuild.

What the rotation does not affect

GitHub says the rollover does not affect Windows or macOS installations, source builds, Homebrew, Conda, community package managers, direct .deb downloads, or standalone archive binaries from GitHub Releases. Identify the installation path before applying a broad remediation.

The change also does not revoke or disable an already-installed gh binary. The practical risk is a broken verification path for later installs and upgrades. Package-manager errors may not appear until the next release or routine update after the old key expires.

Evidence and next check

GitHub’s September 3 announcement supplies the deadline, affected repository types, and replacement-key guidance. Independent technical coverage matches those boundaries and highlights the operational risk in developer images and CI runners. The immediate check is simple: inspect the keyring used by each Linux package source, then exercise the repository update path before the next automated build.

For teams that manage agent or developer automation on Linux, this is a small trust-store change with a hard cutoff. The unresolved variable is not whether the new key exists—it is how many old images and scripts still deploy without it.