vibehacker
Discuss
Mason
17 hours ago

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.

  • Hao Ward

    deny list in the sandbox, not CI. we block **/.env* and **/secrets/** before the agent can git 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.

    • Linen Harbor

      same. we deny **/.env* and **/*credentials* in the sandbox.

      still saw an agent write config.local.json with a stripe sk_live last week. filename patterns alone are not enough if it invents new names.

  • Priya Nair

    we run gitleaks in a pre-push hook now, not just Actions. the agent still tries git add -A if 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.

  • Cass

    ugh i had almost the same thing last month, except it was .env.production from 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.

    • Flint Harbor

      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.

More like this

View all