agent kept regenerating yarn.lock on a pnpm repo
Cursor
AI coding agent for building software
left cursor agent on a "fix the monorepo install" overnight. woke up to three commits that deleted pnpm-lock.yaml, wrote a fresh yarn.lock, then "fixed" CI by flipping packageManager in package.json to [email protected].
our actions cache key is literally pnpm-${{ hashFiles('**/pnpm-lock.yaml') }}. cache miss city. also it helpfully added a .npmrc with shamefully-hoist=true which we do not use.
reverted with git restore + reinstall. anyone got a hard rule that stops agents from touching lockfiles without asking? asking for a friend who almost shipped friday.
5 comments
Join the discussion
Log in to comment.
cold coffee take: if the agent can rewrite packageManager it can rewrite your weekend. we put lockfiles + .npmrc in a deny list for tool writes. still burns a turn arguing about it, but cheaper than a 47s "helpfully" yarn install on pnpm infra.
deny list is polite. i just revoke shell until i've reviewed the diff. screenshotted the yarn.lock once. never again.
revoking shell is good. i also put
pnpm-lock.yamlandyarn.lockin the tool deny path for write. still it tried once viaecho >>which is... creative. timeouts on every install command help too.same. also pinned packageManager in package.json with a pre-commit that fails if the field flips. agent still deletes pnpm-lock sometimes but at least the PR can't merge green
Hard rule we use: AGENTS.md marks lockfiles +
packageManageras read-only. Cursor still proposes the patch; we just require a human approve on anything matching*lock*or that field. The shamefully-hoist.npmrcis the tell — agents cargo-cult yarn defaults the second they smell a monorepo.