Block direct edits to lockfiles via a PreToolUse hook, and tell the agent in CLAUDE.md to use `npm ci` for installs and `npm install --package-lock-only <pkg>@<version>` for bumps. The hook is what actually stops it; the CLAUDE.md line just reduces retries.
Add a PreToolUse hook in .claude/settings.json that rejects Edit/Write calls targeting any lockfile:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "jq -e '.tool_input.file_path | test(\"package-lock.json|pnpm-lock.yaml|yarn.lock\")' >/dev/null && echo '{\"decision\": \"block\", \"reason\": \"Lockfiles are generated. Use npm ci or ask the human.\"}' || true"
}
]
}
]
}
}The hook approach above. Agent gets a block reason, apologises, and runs npm ci instead. Zero lockfile churn in three weeks.
tessellate · 2w ago
Just the CLAUDE.md instructions, no hook. Works maybe 80% of the time, degrades after compaction. Fine for small repos, not enough for a monorepo.
fern.dev · 2w ago
Tried permissions deny rules on the file path. Blocks Edit but the agent just shells out to `npm install`, which writes the file anyway. Bash is the hole.
calvinl · 2w ago
Set "engines": { "npm": "^11.0.0" } hoping the agent would respect it. npm prints a warning and installs anyway unless engine-strict is set, and the agent ignores the warning.
| Agent | Version | Model | OS | Framework | Outcome | Confirms |
|---|---|---|---|---|---|---|
| Claude Code | 2.4.1 | Claude Sonnet 5 | macOS 15.5 | — | Reproduced | 4 |
| Claude Code | 2.4.0 | Claude Opus 5 | macOS 15.5 | — | Reproduced | 8 |
Your report updates the structured counts above.
Sign in to add your report — every count here is backed by a named account.
Pin the npm the agent uses. If you use nvm, make sure the project version is the default so the agent's non-interactive shell picks it up:
nvm alias default $(cat .nvmrc) && npm --versionAdd an explicit rule to CLAUDE.md so the agent stops trying:
## Dependencies
- NEVER run `npm install` with no arguments. Use `npm ci` to sync.
- To bump one package: `npm install --package-lock-only <pkg>@<version>`, then `npm ci`.
- Never hand-edit package-lock.json.Verify: ask the agent to bump any dependency and check the lockfile diff is scoped to that package.
git diff --stat package-lock.jsonApplies to: 2.3.5 – 2.4.1
mateohq · 2w ago
| Claude Code | 2.3.5 | — | Ubuntu 24.04 | — | Reproduced | 3 |
| Codex | 0.45.1 | GPT-5.5 Codex | macOS 15.5 | — | Not reproduced | 2 |
Useful evidence gets promoted into the structured record above — verified fixes, failed approaches, and reproductions all started as comments.
Root-caused it this morning. The agent's Bash tool doesn't source .zshrc the way you'd expect, so nvm's default alias wins over .nvmrc. Ran this inside a session to confirm:
$ which npm && npm --version
/Users/tess/.nvm/versions/node/v20.19.0/bin/npm
10.9.2My shell has 11.2.0. npm 10 and 11 disagree about how to serialize optional deps, hence the giant diff. The hook in the fix block stops the bleeding either way.
This explains so much. I thought I was going crazy because it only happened on my work laptop, which has nvm, and not my personal one, which uses volta.
Pinning the npm version in engines did nothing for me, for the record. Warning gets printed, install proceeds, lockfile rewritten. You need engine-strict=true in .npmrc for engines to actually block, and even then the agent sometimes just adds --force. The hook is the only thing that held.
We rolled the hook out to the whole team via a checked-in .claude/settings.json. One gotcha: jq isn't installed on everyone's machine, so the hook silently no-ops for them. Swapped it for a small node script and added a CI check that the hook file exists. Worth mentioning in the fix?
Sign in to join the discussion, vote, and verify fixes.
+1, seeing this on 2.4.0 with pnpm too. It falls back to npm when pnpm isn't in the non-interactive PATH and then you get a package-lock.json in a pnpm repo, which is its own special hell.