It started at 1am on a Tuesday. I was rotating a Cloudflare API token — routine stuff, the old one was about to expire. I updated the .env in the project I was working on, ran the deploy, everything was fine. Then the staging environment for a different project broke. Same token, different .env, still pointing to the old value.
I fixed it. Then a third project broke the next morning.
That's when I ran the command that changed everything:
$ find ~/dev -name ".env" -not -path "*/node_modules/*" -not -path "*/.git/*"
./boundless-learning/.env
./gitpulse/.env
./gitpulse/api/.env
./noxterm/website/.env
./blindspot/.env
./blindspot/api/.env
./112schade/.env
./bitz-snoek/.env
./playnist/.env
...
$ find ~/dev -name ".env" -not -path "*/node_modules/*" -not -path "*/.git/*" | wc -l
47
Forty-seven .env files. On one machine. I sat there staring at the terminal for a full minute.
The audit
I spent the next hour opening every single one. Here's what I found:
The duplicates. My Cloudflare API token — the one that just broke three projects — appeared in 6 different files. An OpenAI API key was in 8. The same Postmark server token was in 4 projects, two of which I hadn't touched in over a year.
The expired ones. A Stripe test key that had been rotated months ago was still sitting in three .env files. It didn't work anymore, but I'd never cleaned it up.
The dangerous ones. A healthcare API project had a .env with a production database connection string. Full admin credentials. The project was archived — I hadn't opened it in 8 months. But the credentials were still valid. Anyone with access to my machine could have connected to a production database with patient-adjacent data.
The forgotten ones. A side project from early 2024 — a weekend experiment I'd completely forgotten about — still had a live Stripe secret key in its .env. Not a test key. The real one. Connected to a real account with a real credit card.
That was the moment. Forty-seven plaintext files with zero authentication, scattered across my filesystem, containing credentials I couldn't even remember storing.
The migration
I decided to move everything to the macOS Keychain using NoxKey and delete every .env file on my machine. The whole process took one afternoon.
# Step 1: Import the .env file
$ noxkey import noboxdev/gitpulse .env
✓ Imported 4 secrets
# Step 2: Verify everything landed
$ noxkey ls noboxdev/gitpulse/
noboxdev/gitpulse/DATABASE_URL
noboxdev/gitpulse/OAUTH_CLIENT_SECRET
noboxdev/gitpulse/OPENAI_API_KEY
noboxdev/gitpulse/POSTMARK_SERVER_TOKEN
# Step 3: Peek at a value to confirm it's correct
$ noxkey peek noboxdev/gitpulse/OPENAI_API_KEY
sk-proj-...
# Step 4: Test that it actually works in the shell
$ eval "\$(noxkey get noboxdev/gitpulse/OPENAI_API_KEY)"
# → Touch ID → secret loaded
# Step 5: Delete the file
$ rm .env
For projects that shared secrets — like the Cloudflare token that lived in 6 places — I stored it once under a shared prefix:
$ noxkey set shared/CLOUDFLARE_API_TOKEN --clipboard
✓ Stored shared/CLOUDFLARE_API_TOKEN
One token. One location. Accessible from any project. When I rotate it next time, I update it once. Not six times.
The healthcare API credentials got strict mode — always requires Touch ID, even during a session unlock:
$ noxkey strict noboxdev/healthcare-api/DATABASE_URL
✓ Marked as strict — always requires Touch ID
The first week
I won't pretend it was seamless. The first two days were friction city.
Every time I opened a terminal, my muscle memory reached for the .env that wasn't there anymore. I nearly caved on day two — debugging a webhook integration, restarting the server fifteen times in an hour. Touch ID fifteen times.
Then I discovered session unlock:
$ noxkey unlock noboxdev/blindspot
✓ Session unlocked — Touch ID skipped for noboxdev/blindspot/* until session expires
One Touch ID, then every get under that prefix skips the prompt. That changed everything. By day four, the new workflow felt natural.
The AI agent problem I didn't know I had
Two weeks after the migration, I was pair-programming with Claude Code. The agent needed the Postmark token to test an email integration. Old workflow: it would have read my .env and the raw token would be in the conversation context. Logged. Visible. Potentially leaked in an error message.
Instead, the agent ran noxkey get. NoxKey detected the agent by walking the process tree, encrypted the value with AES-256-CBC, wrote a self-deleting temp script, and returned a source command. The secret reached the shell environment, but the raw value never appeared in the conversation.
I hadn't even been thinking about AI agent security when I migrated. I deleted my .env files because of the duplication and rotation nightmare. The agent safety was a side effect — and honestly, it turned out to be the more important benefit.
Six months later
Key rotation is a non-event. Update in one place. Every project picks it up.
I know exactly what I have. noxkey ls shows every secret on my machine, organized by project.
New projects start clean. Zero credential files in the project directory.
The anxiety is gone. No more "did I .gitignore that?" No more "is that old project's .env still sitting there with live keys?" The secrets are in the Keychain, behind Touch ID. That's it.
The honest downsides
It's macOS only. The principle (use your OS credential store) is universal, but NoxKey is Mac-specific.
Some tools expect .env files. Docker Compose, certain Node.js frameworks. For those, I generate a temporary .env from the Keychain, use it, and delete it.
Onboarding takes an extra step. But every time after the first time, it's simpler.
Delete yours
Run this right now:
find ~/dev -name ".env" -not -path "*/node_modules/*" -not -path "*/.git/*" | wc -l
Whatever number you see — that's how many plaintext files with zero authentication are sitting on your machine right now.
I'm not telling you NoxKey is the only answer. I'm telling you .env files are the wrong answer. Use your Keychain. Use 1Password CLI. Use something with actual authentication. But stop treating plaintext files as secret storage.
brew install no-box-dev/noxkey/noxkey
Top comments (0)