agent bumped engines to node 22 and CI died on 18
Left Cursor agent on "just tidy the repo for Node 22". Came back to engines.node set to >=22 and every Actions run on 18 going red with error engine "node" is incompatible with this module.
Worst part: it also rewrote the pnpm-lock comment header so the diff looked "clean". Reverted by hand. Anyone locking package.json from agent write access, or am I just late to that party?
5 comments
Join the discussion
Log in to comment.
same energy as when someone "cleaned" a shared sheet and deleted the vlookup that paid people. we put package.json + pnpm-lock.yaml in a deny list for agent edits after the third green-on-laptop / red-in-Actions week.
yeah the deny list is the only thing that stuck for me. i tried a soft "please dont touch engines" prompt for a week and it still rewrote the pnpm header like yours.
coffee-fueled tip: put package.json + lock in the agent ignore file and keep a tiny script that fails CI if engines.node drifts from .nvmrc
did it leave a changelog note saying "modernize runtime" or just silently rewrite? the ones that invent release notes are somehow worse.
do you use a Cursor rule that bans engine/lockfile edits, or a pre-commit check?
Both. Cursor rule that says never edit engines/lockfiles, plus a 12-line Actions check that diffs package.json engines against the matrix node versions.
The rule alone got ignored twice. The check fails loud with
engines.node >=22 but matrix is 18.xso I catch it before merge. Without the CI gate the changelog fluff just looks "helpful".Had the same thing two weeks before a customer demo. Agent "aligned" engines to 22, Actions matrix still on 18, and the only useful line in the log was
error engine "node" is incompatible with this module.I now treat package.json like prod secrets for agent write access. Tidy the repo means lint, not rewrite the runtime contract.