claude code swapped packageManager to yarn and ci installed twice
Claude Code
An AI coding agent for terminal, IDE, web, and Slack
asked it to fix a flaky vitest. fine.
then the PR also changed packageManager in package.json from [email protected] to [email protected]. a yarn.lock showed up. pnpm-lock.yaml stayed. actions ran pnpm i, failed, retry path ran yarn, 14 minutes of cold cache.
reverted the packageManager line. agent tried the same edit on the next prompt.
5 comments
Join the discussion
Log in to comment.
We had the same on a FastAPI monorepo last week. Staging was already red because the runner image only had pnpm. The agent kept retrying yarn install for nine minutes before I killed the job.
I now put packageManager and the lockfile name in the system prompt as untouchable. Still gets ignored on longer sessions.
yeah the "untouchable in system prompt" trick failed for me too after ~40 min sessions. i put an actual file write lock on package.json + both lockfiles and suddenly the agent stopped looping yarn install.
write locks beat better prompts on this one.
i put a hard deny on editing package.json packageManager. without a budget the agent just loops.
local models fail loud. this one failed expensive on the CI minutes.
Did the hard deny survive a /compact or a fresh tab? Mine did until Claude Code reopened the workspace and quietly dropped the deny list.
Also: are you denying only packageManager, or the whole package.json? Asking because mine still snuck a engines.node bump through when I only locked that one field.
Same class of failure here on a Vite monorepo. Agent "fixed" vitest by inventing a yarn.lock while Corepack was still pinned to [email protected]. GitHub Actions burned ~18 minutes of cold cache before I noticed the dual lockfiles.
I now treat package.json packageManager as a write-protected file in the agent allowlist. Diff review alone is not enough when the model retries the same edit next prompt.