Clarify "an authentication token will be stored internally" -- where is the token stored?

https://cli.github.com/manual/gh_auth_login

an authentication token will be stored internally

Where and how exactly is the token stored? Is it in plaintext? The docs should make clear.

Aha, the OAuth credential is stored in plaintext in ~/.config/gh/hosts.yml.

github.com:
    user: hickford
    oauth_token: 
    git_protocol: https

Better to use https://github.com/GitCredentialManager/git-credential-manager

So better to use Git Credential Manager which supports a variety of secure platform-specific credential stores https://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/credstores.md

Yes, as you've discovered, the token is stored in plain text. We plan to improve that; follow #449 for updates.

Git Credential Manager is indeed great for managing credentials for git operations such as clone and push. The same token can't easily be used for GitHub API operations that gh needs to support commands working with issues, PRs, and similar. This is why gh needs its own token separate from git credentials.

@mislav

@mislav the docs remain unclear, possibly inaccurate. Please could you reopen this issue? https://cli.github.com/manual/gh_auth_login

an authentication token will be stored internally

What does that mean?

@mislav

@mislav the docs remain unclear, possibly inaccurate. Please could you reopen this issue? https://cli.github.com/manual/gh_auth_login

an authentication token will be stored internally

What does that mean?

It would be helpful to include a note in the documentation specifying where the authentication token will be stored on different operating systems. On macOS, it will be stored in the Keychain, on Linux it will be stored in the GNOME Keyring using the Secret Service dbus interface, and on Windows it will be stored in Wincred.

Reference PRs:
#7043
cli/gh-webhook#9

Additionally, if you don't have GNOME Keyring running, gh will store the token in plain text. I'm not sure if that's a bug or a feature, but it'd be nice to somehow be aware of it.

This is an incredible oversight and the addition to the docs is NOT enough. There should be a clear unmissable warning that credentials are stored in PLAIN TEXT! Even when reading the docs I would have assumed that there would be some kind of hint that secure storage failed and the credentials are stored as plain text...

As a comparison docker also fails back to plain text storage but gives a very clear and unmissable warning when it does. gh should be the same.

Or the GCM docs re plaintext: https://github.com/git-ecosystem/git-credential-manager/blob/release/docs/credstores.md#plaintext-files

@assignUser

@assignUser, that should be happening since v2.35.0 which went out with this PR: #7781

If that's not working for you, please raise a bug.

Yes there is a message now, thanks for the info.

IMO pretty meh on visibility, a link to the docs with regards how to prevent this/correctly configure a different back end would be good.

⚠️ No compatible secret storage detected. Saving credentials in PLAIN TEXT.:warning:
See https://cli.github.com/manual/gh_auth_login for configuration details.

Currently there is no details on how to configure the system keychain so gh detects it or which services are supported. Compare again to detailed GCM docs.

Again the plain text fallback is ok and permissions seem to be set correctly as well. The communication of this practice (and how to fix it) for the user is the issue.

@assignUser

agreed @assignUser +1

@assignUser

+1 @assignUser . Indeed, after seeing this warning and reading the docs, I still have no clue of what to do to fix this and get the credentials stored in a safer encrypted form.

I guess I'm mildly amazed that even though I am connecting to github with ssh using a private/public key pair, on a daily basis, somehow github comes up with a LESS secure mechanism to add new capabilities for the API. I would have thought that at a bare minimum you could have encrypted the token with my public key, which you already have.

I created #10108 to try and make some improvements on the functional behaviour (separate from writing docs). Please drop your thoughts in there if you have any.

@3f6a

@3f6a sorry for this very late answer

I still have no clue of what to do to fix this and get the credentials stored in a safer encrypted form

I have had some issue with getting gh to store my creds in the keyring (kwallet) when using plasma on pop_os.

I had to look into the code of the go package that handles the keyring interaction and it only works with a secret service wallet named default. If you have a default wallet that is named something else (e.g. kdewallet as that is required to unlock on login) you can add the following snippet to ~/.config/kwalletrc to make it work.

[org.freedesktop.secrets.aliases]
default=kdewallet

Hope this helps and happy new year everyone!

@assignUser

@assignUser Thanks. I'm not using pop_os. Any idea what I have to do on Ubuntu ?

Sorry can't really say, I haven't had issues on vanilla Ubuntu (Unless using KDE and then the solution from above applies). But as pop_os is based on ubuntu I'd assume a similar issue with no default secret service wallet. I referenced https://wiki.archlinux.org/title/KDE_Wallet to unlock kwallet on login and find the fix above, good luck.

Still an issue on FreeBSD 14.3 (as of 13 October 2025). Yes, it notes that it's storing the credentials in plain text:

✓ Configured git protocol
! Authentication credentials saved in plain text

however it still neglects to say where (yes, I eventually found it in .config/gh but the app knows where it put it and should reveal that!)

It wasn't until after I'd done the search through my files that I found this issue describing the problem.

@nbriggs

@nbriggs Can you please confirm if running gh auth status will show you token storage path/type?

@babakks

@babakks - yes, it does. It didn't occur to me to do that, given I'd just successfully logged in.

I looked at installing kf6-kwallet for secure storage, but it requires installing an additional 30 packages at 350 MB, none of which I need since this is a headless machine on which there is NO Qt development.

I can also confirm same situation, running Debian WSL, i.e. a headless system which doesn't have a key storage solution installed by default (at least not one that gets used automatically by gh).

The warning is there, BUT it is small and it does not include where the credentials are stored
gh auth status shows where they are, BUT doesn't produce a warning of the situation
No information on files used can be found in the documentation
No recommendation on good solutions for non-GUI environments either in the docs or even in these discussions and issues (that I have come across so far)

I have dropped using the built in oauth tokens (because they stay active FOREVER even if you create a new one or extend scope, unless you remove the entire app from your settings entirely) and am using PATs explicitly. That would be a bit painful usually especially with different tokens for different projects but the 1PW integration makes it bearable: https://developer.1password.com/docs/cli/shell-plugins/github/

Navigation Menu

Repository navigation

Clarify "an authentication token will be stored internally" -- where is the token stored? #5961

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Clarify "an authentication token will be stored internally" -- where is the token stored? #5961

Description

Activity

hickford commented on Jul 18, 2022

hickford commented on Jul 18, 2022

mislav commented on Jul 20, 2022

hickford commented on May 29, 2023

chrheg commented on Jun 2, 2023

jdnavarro commented on Sep 15, 2023

assignUser commented on Oct 11, 2023

williammartin commented on Oct 18, 2023

assignUser commented on Oct 20, 2023

geekyayush commented on Feb 5, 2024

3f6a commented on Mar 16, 2024

Stabledog commented on Dec 20, 2024

williammartin commented on Dec 20, 2024

assignUser commented on Jan 1, 2025

3f6a commented on Jan 1, 2025

assignUser commented on Jan 2, 2025

nbriggs commented on Oct 13, 2025

babakks commented on Oct 14, 2025

nbriggs commented on Oct 14, 2025

LinusSch commented on Mar 10, 2026

assignUser commented on Mar 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions