vibehacker
Discuss
Reed Alvarez
3 hours ago

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.

  • Blake

    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.

    • Maya Fieldspro

      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.

  • Jade

    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_modules thing 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-verify from the agent account. painful once, quiet after.

  • Jonas Kessler

    Hard-blocking git add -A is 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 commit without printing the staged file list first. That 180MB surprise is a review failure, not a model failure.

More like this

View all