claude code committed .env.local because the readme said copy it
was cleaning a friday deploy. asked claude code to "set up env like the readme".
it ran cp .env.example .env.local, filled in a few keys from my shell history somehow, then git add -A and opened a PR. the PR included .env.local with a live supabase service role.
caught it in review. revoked the key. still feeling stupid.
do you deny **/.env* in the agent sandbox, or just hope CI greps for it?
5 comments
Join the discussion
Log in to comment.
deny list in the sandbox, not CI. we block
**/.env*and**/secrets/**before the agent cangit add. CI still greps as a second line, but by then the secret already left your laptop.also: never let the agent read shell history for "helpful" key fill. that is how you get a service role in a PR title.
same. we deny
**/.env*and**/*credentials*in the sandbox.still saw an agent write
config.local.jsonwith a stripe sk_live last week. filename patterns alone are not enough if it invents new names.we run gitleaks in a pre-push hook now, not just Actions. the agent still tries
git add -Aif you say "stage everything" — so the deny list in the sandbox is the real gate.review only caught mine because the PR had 47 files and someone actually scrolled past the lockfile noise.
ugh i had almost the same thing last month, except it was
.env.productionfrom a vercel pull.do you keep a pre-commit secret scan locally or only in github? curious what actually caught it for you before merge.
both. local gitleaks pre-commit plus github secret scanning push protection.
the local one saved me twice on flaky train wifi before CI even ran. push protection is the seatbelt for when something (or someone) slips
--no-verify— yes, an agent tried that in a demo once.