If an AI agent deleted and regenerated your lockfile, treat the whole file as a fresh set of version decisions. Compare resolved versions against the old file, check what was added or removed, and decide which changes you actually want. A lockfile is a record of what you tested, so rebuilding it discards that record.
Why agents do this
Lockfile errors are annoying. A merge conflict, a mismatch between the manifest and the lock, or a stubborn install failure can make deleting the file and running install again look like a quick fix. Agents trained to get a build passing will often try it.
The npm documentation explains why the result is not neutral. If a project has a package lock, the installation of dependencies is driven by that lock. The CI oriented install command is stricter: it needs an existing lockfile, and if dependencies in the lock do not match package.json it exits with an error instead of updating the lock. It never writes to package.json or the lock, so installs are essentially frozen.
Delete the lock and that frozen state is gone. The next install resolves every range fresh, and any range that allows newer versions can move.
What can change in one regeneration
- Direct dependencies move to the newest version their range allows.
- Transitive dependencies, which you never chose, move too.
- Packages that were removed from the registry or deprecated since your last install may be replaced or dropped.
- Integrity hashes change along with versions, so a reviewer cannot eyeball them.
None of this is automatically bad. The risk is that the change is large, the pull request looks like noise, and a reviewer approves it without seeing a risky update inside it. That matches the pattern in what to check in a lockfile diff during code review.
How to see what actually moved
- Measure the size. Run
git diff --staton the lockfile. A rewrite of thousands of lines for a one line manifest change is a red flag. - Restore the old lock next to the new one. Keep a copy of the previous file so you can compare package by package.
- List version changes, not line changes. Use your package manager's tree output on each lock, then compare the two lists for names that changed version.
- Look at additions and removals separately. New names need the same vetting as any new dependency.
- Check direct dependencies first. Those are the ones your code calls. Transitive changes matter, but start with what you import.
If most of the diff is unwanted, the simplest recovery is to restore the old lockfile from version control and then apply only the change you intended, for example a single package upgrade through the package manager. The related post on regenerating or resolving a lockfile conflict by hand gives the decision in a merge conflict.
Stop it happening again
Tell the agent not to delete or hand edit lockfiles in your instruction file, and ask it to explain when it believes one is broken. Have CI install with the strict, lock respecting command, so a manifest and lock mismatch fails loudly. Consider a pull request rule that routes any lockfile change above a size threshold to a named reviewer.
Quick check
Is regenerating a lockfile ever the right call?
Yes, for example after a deliberate large upgrade. The difference is that a person chose it, reviewed the resulting diff and recorded why. An agent doing it silently to clear an error is the pattern to stop.
Does the strict CI install protect me if the lockfile was rewritten?
Partly. It makes the install match the committed lock, so it will reproduce whatever the rewritten file says. It does not tell you the rewrite was a good idea. Review is still needed.
Safeguard's SBOM and dependency scanning reads your lockfile, so after a regeneration you can see the new component list and any known vulnerabilities attached to it. You can try it with the free scan at gold.safeguard.sh/scan.
Sources
- npm Docs, npm ci: https://docs.npmjs.com/cli/v10/commands/npm-ci
- npm Docs, npm install: https://docs.npmjs.com/cli/v10/commands/npm-install
Last reviewed: 19 October 2026.
