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

A developer demonstrated that adding a .env file to .gitignore and running git rm --cached does not remove a committed API key from Git history, since git log --all -- .env still surfaces the commit that introduced it. The writeup notes that GitHub's user-level push protection is enabled by default and blocks secrets from being pushed to public repositories on GitHub.com, while repository-level push protection is off by default and requires GitHub Secret Protection. The developer advises treating any key that reached a pushed commit as exposed and rotating it with the provider rather than simply deleting the file.

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. 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 From Penloom Studio's free AI lessons: penloomstudio.com https://penloomstudio.com/landing-cogloom-motion.html