GitHub work fits into one terminal client
GitHub CLI covers the service work that plain git does not. Pull requests, issues, repository creation, releases, Actions runs, Codespaces, gists, and API calls all sit under gh. The README supports GitHub.com, Enterprise Cloud, and Enterprise Server 2.20 or newer. That breadth is why it earns a place on a developer machine: it reduces browser switching without pretending that Git itself has changed.
The distinction from hub is useful. GitHub describes hub as a proxy around git, while gh is a standalone program with its own command tree. That choice makes commands such as gh pr checkout, gh run watch, and gh release create explicit. It also means old scripts written around git hub-style-subcommand behavior do not transfer mechanically. Lazygit solves another problem again, giving local Git a terminal interface while leaving hosted-service operations mostly outside its scope.
The official client follows GitHub features quickly
Release v2.98.0 added worktree support to gh pr checkout and semantic or hybrid modes to issue search. Those are service-specific features that a generic Git client is unlikely to expose promptly. The same release fixed gh status, attestation retries, noninteractive project output, and whitespace handling in release scopes. For teams standardized on GitHub, one maintained client is easier to teach than a pile of curl scripts.
That closeness to GitHub cuts both ways. gh is a poor fit for a GitLab-first organization, and some commands depend on server capabilities or permissions that vary by host. The open issue count was 1,080 issues and pull requests on August 25, 2026, which describes a busy product and contributor queue rather than 1,080 confirmed defects. Recent activity includes both user reports and active pull requests, so the queue must be read alongside the same-day push.
Authentication is easy to start and worth configuring carefully
Interactive use begins with gh auth login, which can authenticate to GitHub.com or another hostname and store credentials through the available system store. Automation can supply tokens instead. That second route needs care: a token should have only the permissions its commands require, and a script should select the intended host when several GitHub instances are configured.
The rough edge is error diagnosis. Open issue #14053 reports that gh auth status can label rate-limit or network failures as an invalid token and recommend reauthentication. That matters in CI, where replacing a healthy credential would not fix an outage. Treat the message as one signal, then check connectivity and API rate limits before rotating secrets. The project was pushed on August 25, so the report sits in an actively maintained queue.
What happened when we ran it
Our sandbox installed 463 Go packages in 65 seconds, then built the checkout in another 66 seconds. The repository was 23 MB with 1,358 files and roughly 272,998 lines of source at commit 5d3c481. That is a substantial command-line application, yet the initial source build completed without needing secrets or privileged container access.
The test stage did not finish cleanly. After 382 seconds, the Go test summary counted 224 passing packages and 2 failing packages out of 226. The supplied log tail shows successful results for packages including jsoncolor, option, search, set, and surveyext, followed only by the final FAIL. It contains no failure message from the two packages, so assigning a cause would be guesswork.
That result changes the contributor recommendation more than the user recommendation. People installing a published binary do not need to compile 272,998 lines or run 226 package tests. Contributors and downstream packagers do. They should reproduce the two failures with fuller logs before treating the checkout as clean, and they should expect the complete test command to take materially longer than the 66-second build on a 3-CPU container.
Release verification is unusually concrete
The project publishes packages and precompiled binaries for macOS, Linux, and Windows, with platform-specific installation pages. Starting with v2.93.0, GitHub says gh releases are immutable. Since v2.50.0, the project has also published build provenance attestations, and the README demonstrates verification through gh at verify or Sigstore's cosign. That gives security-conscious teams a documented check beyond comparing a downloaded filename.
Version v2.98.0 also carried a security fix for gh codespace ports forward. The release says the local forwarded port had been bound to every available network interface by default and advises affected users to update. This is a concrete reason to keep the client current, especially on laptops that move between trusted and public networks. Pinning an old binary for reproducibility needs an update process, not permanent neglect.
Use it for GitHub, not as a replacement for Git
GitHub CLI is best when hosted workflow is the task: reviewing a pull request, watching an Actions run, creating a release, querying the API, or opening a Codespace. Its built-in extension system and agent skill widen that surface without forcing every feature into the core binary. The manual remains the better reference once the README's installation and positioning pages run out.
Local history editing still belongs to Git or a focused interface such as Lazygit. Cross-forge automation belongs in a tool that models several providers. Within its actual boundary, gh is an easy recommendation for GitHub users. The caveat from our 382-second test run is for builders: source compilation worked, but the checkout did not earn a fully clean test result in our container.