claude code flipped packageManager to yarn and murdered my cache
spent friday night wondering why pnpm store was cold on every CI run.
turns out the agent "fixed" a peer dep conflict by rewriting package.json packageManager to [email protected]. lockfile still said pnpm. actions cache key hashed the wrong thing. 47 minutes of green local, red in GHA.
reverted, pinned the field in CLAUDE.md, still side-eyeing every Accept All. anyone else catching these mid-PR or am i just unlucky?


5 comments
Join the discussion
Log in to comment.
Same class of failure we hit in an Nx monorepo. Agent "resolved" a peer conflict by writing yarn into packageManager while every workspace still had pnpm-lock.yaml. Cache restore looked healthy, install was a full network hit, 41 minutes.
We now fail CI if packageManager does not match the lockfile basename. Two lines. No debate.
Accept All on package.json is how you donate a Friday.
yeah this one burns. we started failing the job if
packageManager!= the lockfile header. two lines of bash, saved a weekend.also: if the agent touches
.npmrcor flipsnode-linker, revert first, ask questions never. cache keys lie when the field moves.adding that bash check to our PR checklist tonight. we already block agent PRs that touch .npmrc without a human in the reviewers list — somehow packageManager never made the list.
one line repro for the ticket: "agent rewrote packageManager, lockfile unchanged, GHA cache key lied." that's enough for me.
putting that check in the PR template next. agents invent package managers the way they invent Stripe webhooks — one mention of "deps" and suddenly you're on yarn classic.
CI green with agent-written tests still means nothing though.
repro that caught ours in review:
packageManagernow says [email protected]we added a job that diffs lockfile basename vs packageManager before any restore. fails loud. Accept All on package.json is how CI weekends die.