Summary
gh auth status currently reports that a token is invalid when the underlying failure is actually at the network/transport layer. In restricted environments this sends users toward re-authentication even though their credentials may be fine.
Example Use Case
A concrete case is running gh auth status inside a sandboxed or otherwise restricted environment where DNS or outbound network access is blocked. In that situation the human-readable output says the token is invalid, but the actual failure is a transport error such as lookup api.github.com: no such host. Running the same command outside the restricted environment succeeds without re-authentication.
This can also apply in CI, containers, devboxes, or corporate network setups where GitHub is temporarily unreachable or DNS/proxy configuration is broken.
Reproduction
- Run
gh auth status in an environment with blocked DNS or blocked outbound access to GitHub.
- Observe that the human-readable output says the token is invalid and suggests
gh auth login or gh auth logout.
- Run
gh auth status --json hosts or GH_DEBUG=api gh auth status.
- Observe that the real error is transport-related, for example
lookup api.github.com: no such host.
- Run the same command outside the restricted environment and see authentication succeed.
Current Behavior
- Human-readable output reports an authentication problem.
- Machine-readable/debug output can already show the real transport error.
Expected Behavior
- Human-readable output should distinguish invalid credentials from transport/network verification failures.
- Re-authentication guidance should only be shown for actual invalid-credential failures.
- If maintainers prefer a minimal change, JSON output can remain backward compatible while the human-readable messaging is corrected.
Additional Context
I already implemented a draft fix in PR #12878, which keeps the JSON shape stable and only changes the human-readable classification/message path.
Summary
gh auth statuscurrently reports that a token is invalid when the underlying failure is actually at the network/transport layer. In restricted environments this sends users toward re-authentication even though their credentials may be fine.Example Use Case
A concrete case is running
gh auth statusinside a sandboxed or otherwise restricted environment where DNS or outbound network access is blocked. In that situation the human-readable output says the token is invalid, but the actual failure is a transport error such aslookup api.github.com: no such host. Running the same command outside the restricted environment succeeds without re-authentication.This can also apply in CI, containers, devboxes, or corporate network setups where GitHub is temporarily unreachable or DNS/proxy configuration is broken.
Reproduction
gh auth statusin an environment with blocked DNS or blocked outbound access to GitHub.gh auth loginorgh auth logout.gh auth status --json hostsorGH_DEBUG=api gh auth status.lookup api.github.com: no such host.Current Behavior
Expected Behavior
Additional Context
I already implemented a draft fix in PR #12878, which keeps the JSON shape stable and only changes the human-readable classification/message path.