Dotfiles and agent configs: secrets hiding in plain sight
Dotfile repositories are where tokens go to be forgotten. A .gitconfig with a stored credential helper, a .npmrc with a registry token, .env files for a dozen projects, shell history with a pasted API key, agent configs with a provider key — all of it sitting in a directory that is often a public GitHub repo or an unencrypted backup. Nobody commits these deliberately. They leak because config files are the one place where “it just needs to work” beats “this is a secret.”
The usual hiding spots
Start with the obvious ones. .env files are the most common: projects expect them, dotfile sync tools copy them, and a KEY=VALUE parser is all it takes to turn a directory scan into a credential dump. Registry and package-manager configs — .npmrc, .pypirc, .gemrc — routinely contain tokens with long expiry dates. Git config can embed credentials through helper programs or plaintext URLs that carry usernames and passwords. And anything pasted during setup counts too: a session key in shell history, a token in a scratch file.
Agent configs add a new layer. AI coding agents store provider keys, MCP server tokens, and OAuth sessions in their own config directories, frequently with permissive file modes because a setup wizard wrote them. A dotfile repo that includes an agent config directory is a direct route to a billable API account.
Why these are worse than they look
Each of these looks innocuous in isolation. A token in a config file is not in git history with your name on it, and it is not in a log file. But dotfiles are duplicated everywhere: cloned to new machines, backed up to cloud storage, shared between work and personal setups. One sync tool and one public repo is all it takes to expose dozens of credentials at once. The blast radius is not one service — it is every service the configs touch.
Scrubbing what is already there
If you are reading this, the secrets are probably already in your dotfiles. The fix has two parts. First, scan: enumerate the directories, find files that look like key-value assignments, and flag values that match known patterns or score high on entropy. Second, redact: replace the discovered values while keeping a backup of the originals so nothing breaks irrecoverably.
Scanning should be careful by default. A dry run that shows what it found before changing anything is the only safe way to do this at scale. Pattern matching alone misses values that do not fit a known format, so combine known-value matching with pattern detection and entropy scoring to catch both the token you know about and the one you forgot. For anything already committed, two-layer redaction — known values plus patterns — applied to local data stores, followed by a database rebuild, is the closest you get to undoing the leak.
This is exactly the workflow trustless bundles. Its setup wizard scans directories for .env-style files, parses KEY=VALUE pairs, and backs up the originals before importing them into a password store. trustless doctor runs the same scan on demand and reports what it finds. And the trustless dlp scrub-db and scrub-text commands redact known values and pattern matches with a dry-run default and an –apply flag to commit, then rebuild the search index. The project is MIT-licensed and the code is at https://github.com/ikkun1222/trustless, with the command documentation at https://trustless-security.com/docs/.
Before you push your dotfiles repo to GitHub again: what is in it that a stranger could use, and when did you last run a scan that actually looked?