Not by default. The GitHub CLI manual says the web login stores the token securely in the system credential store. If no store is found or it fails, gh falls back to a plain text file, and the insecure-storage flag forces that choice. Run gh auth status to see where your token lives.
What the manual says
The gh auth login manual states that the default authentication mode is a web-based browser flow. When that completes, an authentication token is stored securely in the system credential store. If a credential store is not found, or there is an issue using it, gh falls back to writing the token to a plain text file. The gh auth status command shows the stored location.
There is also an --insecure-storage option, which saves credentials in plain text instead of the credential store. It exists for cases where a store is unavailable, and it should not be a default.
When the fallback happens
The fallback is most likely on machines without a desktop keyring, such as a headless Linux server, a minimal container or a remote development box. The CLI cannot talk to a store that is not there, so it writes the file.
On a personal laptop with an operating system keychain, you normally get the secure path. Do not assume, though. A quick check takes seconds.
Three ways to authenticate, compared
| Method | Where the token lives | Good for |
|---|---|---|
| Browser flow (default) | System credential store, with plain text fallback | Your own laptop |
| --with-token on stdin | Same storage rules after login | Scripted setup using a token you supply |
| GH_TOKEN environment variable | In the environment of that process | Headless automation and CI |
The manual notes that gh will use a token found in environment variables, which suits automation. It also cautions that for fine-grained personal access tokens you should favour setting GH_TOKEN rather than passing them through --with-token, because the scoping can cause confusing behaviour with other resources. In GitHub Actions, the manual suggests setting GH_TOKEN: ${{ github.token }} in the job environment.
A short checklist
- Run
gh auth statusand note the storage location it reports. - If it points at a plain text file on a machine that has a keyring, log out and log in again after fixing the keyring.
- Do not use
--insecure-storageon shared or long-lived machines. - Give the token the narrowest scopes your work needs. The manual lists the minimum scopes for
--with-tokenwith a classic token. - On servers, prefer a short-lived or narrowly scoped token supplied through the environment for that job.
- Revoke tokens you no longer use from your GitHub account settings.
Where Safeguard fits
Safeguard works on the dependency and code side of your software: SBOM and dependency scanning, reachability analysis and policy gates. It does not store or manage credentials, so keep using your password manager, secrets manager or cloud identity for that. You can run a free scan of a project at gold.safeguard.sh/scan.
Quick check
Is the browser login safer than pasting a token?
The manual says the browser flow stores the token in the system credential store, which is the more protective default. Pasting a token still follows the same storage rules.
How do I find where the token is stored?
Run gh auth status. The manual says it shows the stored location.
What should automation use?
The manual points to environment variables such as GH_TOKEN for headless use.
Sources
Last reviewed: 19 October 2026.
