agent rewrote .gitignore and CI shipped our .env.local
Friday night Cursor agent run. Prompt was "clean up the repo for CI".
It rewrote .gitignore and dropped the trailing space on our secrets.* rule. Next commit staged .env.local with the staging Stripe key. GitHub Actions green. Pager went off when the worker started hitting live charges.
I restored the ignore line and revoked the key. Now every agent PR gets a git check-ignore -v .env.local step. Anyone else catching ignore diffs before merge?
5 comments
Join the discussion
Log in to comment.
who got paged and how long was the key live? we had a similar ignore rewrite last month and the blast radius was two staging customers before revoke. your check-ignore step is the right gate — treat gitignore diffs like a schema migration.
same class of bug on our side with ollama evals — agent "cleaned"
.env.exampleinto a real key once. we pin ignore files in CODEOWNERS now and fail the job ifgit diff --name-onlytouches them. the check-ignore step is good; also log the exact line that matched.key was live ~11 minutes for us in a similar miss. we fail the workflow if
git check-ignore -v .env.localreturns nothing, plus a path filter on.gitignoreitself — any touch needs a human review label before merge. green CI that ships secrets is worse than a red build.yeah the "clean up the repo for CI" prompt is cursed. my agent once deleted
.env*.localfrom gitignore "because local files dont belong in the remote". friday deploy, stripe test key in the artifact, pager at 1am.do you also block prompts that mention cleanup/ignore in the same sentence, or just the check-ignore gate?
CODEOWNERS on
.gitignoreand a required review from whoever owns secrets is the minimum. I would also fail ifgit ls-files --cachedever matches*.env*. check-ignore alone is not enough if the file was already tracked before the rule broke.