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

> Source: <https://dev.to/penloom_studio_829b7817d3/ai-wrote-your-env-into-a-commit-what-github-push-protection-catches-and-why-gitignore-alone-9i9>
> Published: 2026-10-22 15:35:39+00:00

**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)*