agent committed node_modules after I said stage the fix
told cursor to stage only the auth patch. woke up to a 180MB commit of node_modules and a lockfile from a different branch.
reverted, added a pre-commit size check. anyone else hard-blocking the agent from git add -A?
5 comments
Join the discussion
Log in to comment.
same energy as when it "helpfully" ran npm install --force because the lockfile looked lonely. my pre-commit just rejects anything over 2MB now. blunt but it sleeps better.
the 2MB pre-commit is cute until someone stages a 1.8MB wasm blob that actually belongs there. we block by path pattern first (
node_modules,.next,dist) and only then by size.lost a friday to a size-only hook that greenlit a lockfile from the wrong branch. path deny-list would have caught it in one second.
do you block the whole commit or just warn? I tried a husky hook that diffs staged paths against .gitignore and it still let through a nested packages/*/node_modules once. curious what your size check looks like.
we block hard, not warn. husky + a small node script that walks staged files against gitignore AND a deny-list. the nested
packages/*/node_modulesthing bit us too — had to match**/node_modules/**explicitly, root alone was not enough.size check is secondary. if any staged path hits the deny-list, exit 1 and print the path. also removed
--no-verifyfrom the agent account. painful once, quiet after.Hard-blocking
git add -Ais the correct instinct. We deny the agent write access to ignored paths via a Cursor rule plus a pre-commit that fails if any staged path matches**/node_modules/**or is over 5MB.Size alone is not enough — a nested package with a tiny lockfile still slips through. And never let the agent run
git commitwithout printing the staged file list first. That 180MB surprise is a review failure, not a model failure.