What does Git's credential.helper do, and how do the store, cache, and keychain helpers differ?

## The problem An HTTP fetch or push is a fresh request that must carry a credential. Without help, Git would prompt on every operation. The credential-helper mechanism is Git's pluggable answer: a small protocol between Git and any external program that can remember or produce secrets. ## The protocol A helper is a program named `git-credential-<name>` (or an inline shell command when the config value starts with `!`). Git invokes it with one of three actions and speaks a simple key-value format on standard input and output: - `get` — Git supplies `protocol`, `host`, and possibly `path`; the helper may reply with `username` and `password`. - `store` — after a request succeeds, Git offers the credential so the helper can remember it. - `erase` — after a rejection, Git tells the helper to forget it. This is the step that clears a revoked or expired token; when a helper misses it, users see the infuriating "it keeps sending the old token" symptom. You can drive the same machinery by hand with `git credential fill`, `git credential approve` and `git credential reject`, which is the fastest way to debug what Git is actually retrieving. ## The bundled helpers **store** — appends `https://user:secret@host` lines to `~/.git-credentials` in cleartext (a different file can be given with `--file`). Persistent across reboots, zero setup, and readable by anything that can read the file or a backup of it. **cache** — starts `git-credential-cache--daemon`, which holds credentials in memory and answers over a Unix socket. Nothing is written to disk. The default timeout is 900 seconds and is configurable, for example `credential.helper 'cache --timeout=3600'`. It is a POSIX mechanism, not a Windows one. **osxkeychain / wincred / libsecret** — delegate to the platform's secret store, so the secret is protected by the OS and by the user's login session. This is the sane default on a workstation. **manager** — Git Credential Manager, a cross-platform helper that can additionally drive interactive OAuth-style flows and store the result in the platform store. ## Configuration details worth knowing `credential.helper` is a *multi-valued* setting: several helpers can be configured and Git asks each in order until one supplies a credential, then offers `store` to all of them. Because values accumulate across config scopes, setting `credential.helper` to an empty string resets the list — the standard way to neutralize something a system-level config imposed. Helpers can be scoped per URL, as in `credential.https://example.com.helper`, so different hosts use different mechanisms. `credential.useHttpPath=true` makes the repository path part of the lookup key, which matters when one host must hold different credentials for different repositories — without it, one entry per host is the granularity. When no helper answers, Git prompts on the terminal, or calls the program named by `GIT_ASKPASS` or `core.askPass` if one is set. In automation, `GIT_TERMINAL_PROMPT=0` turns a would-be prompt into an immediate failure instead of a hung job. ## Choosing one On a workstation, prefer the OS keychain helper. In ephemeral CI containers, prefer not to persist at all: supply the token through an askpass hook or an inline helper that reads it from the environment, so nothing is left in a file on a shared image. `store` is acceptable only where the filesystem is genuinely private and short-lived, and even then it is worth knowing that the secret is sitting in cleartext.