Use a helper that talks to your operating system's secure storage. Git's own docs say the store helper saves passwords unencrypted on disk, while the cache helper keeps them in memory for a short period. Cache is the safer built-in choice. Store is a last resort.
The three kinds of helper
Git's gitcredentials documentation lists credential helpers that cache or store passwords, or that connect to a system's secure storage. Two are built in:
cachekeeps credentials in memory for a short period of time.storekeeps credentials indefinitely on disk.
The third kind is a helper that integrates with the secure storage provided by your operating system, such as a keychain or credential manager. That is usually the right default on a personal machine.
What the store helper writes
The git-credential-store documentation is blunt. Using it will store your passwords unencrypted on disk, and it suggests that you consider a helper that integrates with secure storage instead. The .git-credentials file it creates is plain text, with each credential on its own line, and protected only by ordinary file permissions.
Anyone or anything that can read your home directory can read that file. That includes backup tools, malware running as your user, and a teammate on a shared machine.
In short, the file turns a short-lived login into a standing credential sitting in plain view. If that credential is a password rather than a scoped token, the damage from a single leak is much larger, because the password may also open your account settings.
Choosing by situation
| Situation | Suggested helper |
|---|---|
| Personal laptop with a keychain | OS integrated helper |
| Shared or short-lived machine | cache with a short timeout |
| Headless server with no keyring | cache, or a token supplied per job |
| Throwaway container | Pass a short-lived token through the environment |
In every case, use a token with narrow scope rather than your account password, so a leak is limited and revocable.
How to check what you use
Run git config --show-origin --get-all credential.helper to see which helpers are configured and in which file. If store appears, look for a .git-credentials file in your home directory and decide whether to replace it. After switching, delete the old file and revoke any token that was in it, because the plain text copy may already have been backed up elsewhere.
For personal access tokens, prefer fine-grained tokens with an expiry date, so a forgotten entry stops working on its own.
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 cache helper encrypted?
The docs describe it as keeping credentials in memory for a short period, so nothing is written to disk by default.
Is git credential-store ever fine?
The docs warn that it stores passwords unencrypted. Use it only where nothing safer is available, and use a narrow, expiring token.
Should I put a token in the remote URL?
Avoid it. A URL with a token inside is saved in your repo config and can show up in logs and terminal output.
Sources
Last reviewed: 19 October 2026.
