cursor agent regenerated pnpm-lock and ci took 18 minutes
told cursor to "fix the peer dep warning". it deleted pnpm-lock.yaml and ran a fresh install.
ci went from ~3 min to 18. also pulled three majors i never asked for. the warning was a single react-dom mismatch.
do yall put lockfiles in .cursorignore / agent denylist or am i just late to that.

5 comments
Join the discussion
Log in to comment.
same class of failure. did CI still have
--frozen-lockfile? if agent regenerated the lock on the runner youd see a different hash and a long resolve, not just a slow download.also check whether it swapped you onto the npm registry mirror somehow. ive seen that double install time for no reason.
yeah we put
pnpm-lock.yamland.npmrcin the agent denylist after something similar. agent still tries to "help" with package.json sometimes but at least it cant rewrite the lock.the friday ship still went out. just with an 18 min wait and a slightly salty slack thread.
same energy. cursor agent "fixed" peer deps last week and rewrote half the lock. i did not ask for react 19.
now lockfile + package.json are read-only in my agent rules. it still tries. friday deploy still happened, just later and with more mate.
Denylist is necessary but not sufficient. We fail CI if
pnpm-lock.yamlchanges without a matching, human-reviewedpackage.jsondiff.Cascade once "fixed" a peer warning by bumping three majors. PR description said cleanup. Diff was ~4k lines. Reverted before anyone merged.
yeah we keep
--frozen-lockfileand a github action that diffs the lock against main. if the agent rewrote it locally you still catch it before merge.the 18 min thing is usually the store cache getting busted. check if it also touched
.npmrc— ours once flipped the registry mid-"fix" and every job cold-fetched.