vibehacker
Discuss
Jordan Lee
1 month ago

cursor agent swapped pnpm@9 for [email protected] and GHA burned 38 min

#rants#vibe-coding#tooling
Cursor
AI coding agent for building software

asked Cursor (composer, claude-4.5-sonnet) to "resolve the lockfile conflict" on a monorepo PR. it rewrote packageManager in package.json from [email protected] to [email protected], deleted pnpm-lock.yaml, and left a half-written yarn.lock.

ci on ubuntu-latest did a cold yarn install. 38 minutes. Activity Monitor on my M2 still showed the local pnpm store humming along, so of course it "worked on my machine." cancelled the run after the Actions bill jumped ~$2.40.

now I have package.json and pnpm-lock.yaml on a CODEOWNERS deny for agents. has anyone else seen composer treat packageManager like a suggestion instead of a contract?

7

7 comments

Join the discussion

Log in to comment.

Log in
  • Freya Ramirezpro

    yeah. we started treating packageManager like a schema file after the third time an agent "helpfully" swapped it.

    our rule now: agent can touch source and tests. lockfiles + packageManager + engines stay human-only, and CI fails loud if the field drifts from the committed value. the 38 min cold install is the expensive lesson; the silent yarn.lock stub is the scary one.

    • Noah Singh

      same failure mode hit us on a Prisma schema last month. agent "fixed" a migrate conflict by rewriting schema.prisma and regenerating client — local Next build passed, staging GraphQL gateway started returning null on three fields.

      we added a CI check that diffs packageManager, lockfiles, and prisma/schema.prisma against main and fails if an agent PR touches them without a [human] label. still nervous every rainy pair session though.

      • Liam O'Connor

        ha the [human] label trick is good. we tried a soft warn first and people just ignored it on friday merges.

        now the check fails hard if packageManager or pnpm-lock.yaml drifts without that label. cost me one merge delay last week. cheaper than a 38 min yarn spiral on ubuntu-latest though

  • Pixel

    we caught the same thing when composer "fixed" a lockfile merge on a turborepo.

    ci said pnpm store miss for 22 min before i noticed packageManager had flipped to yarn. now it's in the same CODEOWNERS bucket as .github/** — agent PRs that touch it need a human label or the check fails.

    does cursor even surface the packageManager diff in the apply preview? mine buried it under a 400-line lockfile chunk.

    • Amara Nwosu

      we are two engineers and had the same friday spiral — composer "fixed" a lockfile merge, flipped packageManager, and our ubuntu runner chewed ~40 min of cold yarn while i was asleep in Lagos.

      CODEOWNERS on packageManager + lockfiles is what stuck. apply preview buried the one-line package.json change under the lockfile noise for me too. now i grep the PR for packageManager before i even open the diff.

    • Ash Beacon

      buried for me too. the packageManager line sat under a 600-line yarn.lock chunk. i only caught it because GHA printed error [email protected]: No such file or directory after twenty minutes of silence.

      grep the PR for packageManager before you open the diff. cheaper than another cold install.

  • Kayla

    yeah this one stung. we had composer flip packageManager on a friday afternoon PR and the ubuntu runner spent 41 min inventing a yarn cache we never wanted.

    now i treat that field like a schema. CODEOWNERS on package.json + lockfiles, and a tiny CI step that fails if the string drifts from main. packageManager is a contract, not a suggestion. did the apply preview even highlight the one-liner for you, or was it buried under the lockfile diff?

More like this

View all