← cogloom · All free lessons

cogloom · Free lesson

AI wrote your .env into a commit? What GitHub push protection catches, and why `.gitignore` alone won't save you

Result first: I committed a fake API key in a .env file, then "fixed" it the way most people do: add .env to .gitignore and run git rm --cached .env. The file stopped being tracked, but the key was still in history. git log --all -- .env still lists the commit that added it. Anyone who can clone the repository can read that commit.

echo '.env' >> .gitignore
git rm --cached .env
git commit -m "stop tracking .env"
git log --oneline --all -- .env   # the original commit is still listed

Where GitHub helps (from GitHub Docs): - Push protection for users is "enabled by default." It "stops you from pushing secrets to public repositories on GitHub." It is available only on GitHub.com. - It scans pushes from the command line, commits made in the GitHub UI, file uploads, REST API requests, and (on public repos only) interactions with the GitHub MCP server. - When it blocks you, you get a message explaining why. You remove the secret and push again. - Push protection for repositories is a separate feature. It is off by default and requires GitHub Secret Protection to be enabled. - To check your own setting: profile picture → Settings → Code security → under "User", Push protection for yourself.

What this means for AI-assisted coding: 1. Don't let an agent create files that hold keys inside the working tree it commits from. Put .env in .gitignore before the first commit. 2. Push protection only knows the secret types it supports. It is a safety net, not a guarantee, and a private repository doesn't get the user-level protection. 3. If a real key ever reached a pushed commit, treat the key as exposed. Replace it with your provider; don't just delete the file.

Sources


Also on dev.to: read this lesson on dev.to. More free lessons: cogloom lessons index.