Use a credential helper that talks to your operating system keychain, such as osxkeychain on macOS, wincred or Git Credential Manager on Windows, or libsecret on Linux. Avoid the plain store helper, which the Git documentation says keeps credentials indefinitely on disk. Then check your config for any token embedded in a remote URL.
How Git asks for credentials
Git's gitcredentials documentation explains that when Git needs a username and password, for example for an HTTP remote, it tries a sequence of strategies. If the GIT_ASKPASS environment variable is set, that program is invoked. Otherwise Git can prompt in the terminal. Many remotes accept a personal access token or OAuth token in place of a password, which is why the stored value matters: it is a reusable key.
Credential helpers exist so you do not retype it. Which helper you pick decides where the secret sits.
The options, in plain terms
- store: The documentation says it stores credentials indefinitely on disk. That means a file in your home directory that any process running as you can read.
- Keychain based helpers: The documentation names git-credential-libsecret on Linux, git-credential-osxkeychain on macOS and git-credential-wincred on Windows as popular helpers with secure persistent storage.
- Git Credential Manager: A cross platform helper included in Git for Windows.
The simple and appropriate cases for plaintext, per the same page, are when you do not have secure storage available. A developer laptop usually does.
Steps to tidy up
- Look at your configured helper:
git config --show-origin --get-all credential.helper
- If it shows store, replace it with the helper for your platform.
- Search for old plaintext files and delete them, including the credentials file used by the store helper in your home directory.
- Review remotes for tokens pasted into URLs:
git remote -v
- Revoke any token that was ever saved in plain text, then create a replacement with the narrowest scope and an expiry.
Why scope and expiry matter more than storage
A keychain protects the token at rest, but a process running as you can often still ask for it. That is why a short lived, narrowly scoped token is the better second layer. If it leaks, the damage is limited to one repository for a few days instead of an entire account for a year.
Watch for tokens in other places
Shell history, env files and CI logs collect tokens the same way. A clean Git config does not help if the token is also in a dotfile you sync to a public repository.
Checking a shared or older machine
Older laptops and shared build hosts are where plaintext credentials linger. Search the home directory for the credentials file that the store helper writes, and check any cloned folder whose remote URL contains an at sign before the host name, which usually means a token was pasted in. Replace what you find, rotate it, and note the date. It takes a few minutes and closes one of the most common quiet leaks.
If you want a quick look at what your projects actually resolve, Safeguard offers SBOM and dependency scanning, and there is a free scan at gold.safeguard.sh/scan.
Quick check
Is the store helper encrypted?
The Git documentation describes it only as storing credentials indefinitely on disk. Treat it as readable by anything running as your user.
Should I put a token in the remote URL?
No. It ends up in config files and in command output. Use a credential helper instead.
Sources
Last reviewed: 19 October 2026.
