Claude Code Committed My .env (or Pushed My Secrets to GitHub): How to Fix It

You asked Claude Code to "set up git" or "push this to GitHub," and now your .env is sitting in the commit. Your API keys, your database password, your tokens: all of it, written into the repo.

Breathe. This is fixable, and you're not the first person it happened to. But the order matters a lot, and most advice online gets it backwards. So do these in order, top to bottom, and don't skip the first one even if it feels like the boring one.

The single most important thing to understand: once a secret has been committed, cleaning the repo is not enough. You can scrub it perfectly and still be exposed, because you can't prove nobody copied it in the meantime. The real fix is to make the leaked secret worthless. That's step one.

Step 1: rotate the keys (do this first, always)

Treat every secret in that .env as compromised the moment it landed in git. Not "probably fine." Compromised.

Go to each service that issued a key and revoke the old one, then generate a new one:

• Payment keys (Stripe, etc.), AI keys (OpenAI, Anthropic, etc.), and any third-party API tokens.
• Database passwords and connection strings.
• Any auth secret, session secret, or webhook signing secret.

Then paste the new values into your local .env. This is the step that actually closes the hole. If the repo was pushed to GitHub, bots scrape public commits for keys within minutes, so rotating is not paranoia, it's the job. If you genuinely never pushed and the repo never left your machine, you can weigh skipping it, but when in doubt, rotate. Ten minutes now beats a surprise bill later.

If you pushed to GitHub and the key was a known type, GitHub's own secret scanning may have already emailed you or flagged it. GitHub documents what to do with a flagged secret in Remediating a leaked secret, and the headline is the same as mine: revoke it.

Step 2: get .env out of git tracking

Now stop git from watching the file at all. In your project folder, you (or Claude, if you'd rather) run:

git rm --cached .env
echo ".env" >> .gitignore
git commit -m "Stop tracking .env"

What this does in plain English: git rm --cached tells git to forget the file without deleting it off your disk, and adding it to .gitignore tells git to never track it again. Your real .env stays right where it is and keeps working. Git just stops paying attention to it.

Important: this does not remove the secret from your history yet. The old commits still contain it. That's step 3.

Step 3: scrub it from git history

Deleting the file in a fresh commit is not enough, because git keeps every old version. Anyone who clones the repo can still walk back through the history and read your keys. You have to rewrite the history so the secret was never there.

The two standard tools for this are both free and both maintained:

• git filter-repo, the tool GitHub itself now points to for this.
• BFG Repo-Cleaner, which is simpler for the common "delete this file from all history" case.

GitHub's own walkthrough is Removing sensitive data from a repository. It's the canonical reference, and it's worth following exactly rather than improvising.

A few honest cautions, because this step rewrites history:

• After you rewrite and force-push, anyone else with a clone has to re-clone, or they'll drag the secret back in. Tell your collaborators.
• Forks, pull requests, and cached views on GitHub can still hold the old commit for a while. This is the real reason step 1 exists: you can never fully guarantee the secret is gone from everywhere, so the durable fix is that the secret no longer works.

If this is a brand-new repo with one or two commits and no collaborators, the cleanest option is often the bluntest: delete the GitHub repo, remove the local .git folder, and start the repo over with .gitignore correct from the first commit. Then push fresh. No history to scrub because there's no history.

Why /rewind can't save you here

If your instinct was to hit /rewind (Esc Esc), that's natural, and it won't help with this. Rewind only undoes Claude's own direct Write and Edit edits inside the current session. It has no connection to git commits, to pushes, or to your GitHub remote. Per the official Claude Code checkpointing docs, checkpointing tracks file edits Claude makes through its tools, not actions in your git history or on a remote server.

So a committed-and-pushed secret sits completely outside what rewind can touch. Same blind spot a lot of people hit the hard way. If you want the full picture of what rewind does and doesn't cover, we wrote it up here: Does Claude Code's /rewind Undo Deleted Files?.

Step 4: make sure it never happens again

The root cause is almost always the same: a .env that wasn't ignored before git first ran. Close that gap and this stops happening.

1. Put .env in .gitignore before you ever run git. If you let Claude initialize a repo, ask it directly: "Add a .gitignore that ignores .env, .env.*, and any local database files, and confirm .env is not tracked before you commit anything."
2. Keep real secrets only in the ignored .env. Never paste live keys into code, into a README, or into the chat with Claude.
3. Turn on GitHub push protection if you use GitHub, so a secret gets blocked before it's ever pushed. GitHub explains it in About push protection.
4. Keep a safety net under .env itself. Here's the catch that bites people: git is deliberately told to ignore .env, which is correct, but it means git has no copy if the file gets deleted or clobbered later. So the same file that's dangerous to commit is also the file with no backup. That's the gap Undeletable closes. It keeps its own byte-for-byte copy of files before Claude touches them, including the .env that git is ignoring, so a bad git move or a stray delete is one /restore away. It runs locally, no account, no upload, one-time $19. Totally optional, the checklist below is the main event.

Get the free checklist

This whole "set it up right the first time" routine lives in the free Claude Code Safety Checklist. It's the plain-English, do-this-then-this version, including the .gitignore setup that prevents this exact mess, and we'll email it to you so you have it on hand. Drop your email and it lands in your inbox.

Already cleaning up a deleted file too, not just a leaked one? Start here: Claude Code Deleted My Files? How to Recover Them. And if you want the full prevention setup, here's How to Set Up Claude Code So It Can't Delete Your Work.

You caught it, you fixed it, and now you know the order. Rotate first, clean second. That's the part almost nobody tells you.

---

Related reading: How to Set Up Claude Code So It Can't Delete Your Work · Does Claude Code's /rewind Undo Deleted Files? · The free Claude Code Safety Checklist · Undeletable