pnpm 'ERR_PNPM_OUTDATED_LOCKFILE' after the agent edited package.json by hand

Not specified by the original author.

TL;DR

package.json changed without a lockfile refresh, so pnpm refuses to install. Run pnpm install, which updates pnpm-lock.yaml automatically, then review the lockfile diff and commit it. Never hand-edit the lockfile to match.

Error

pnpm 'ERR_PNPM_OUTDATED_LOCKFILE' after the agent edited package.json by hand

Steps

1. Confirm the drift: git diff package.json shows the hand edit; git status shows pnpm-lock.yaml unchanged. Expected output: You see the manifest change with no matching lockfile change.

2. Refresh the lockfile: pnpm install. Expected output: pnpm updates pnpm-lock.yaml and the outdated error is gone.

3. Review what moved: git diff pnpm-lock.yaml, checking that only the intended packages changed versions. Expected output: The diff matches the hand edit's intent.

4. Run the test suite to confirm the refreshed graph still works. Expected output: Tests pass on the new resolution.

5. Commit both files together so the next install is deterministic. Expected output: CI with a frozen lockfile goes green.

When to use

• pnpm fails with ERRPNPMOUTDATED_LOCKFILE after someone edited package.json directly
• An agent bumped a version string by hand and skipped the install step
• CI uses a frozen lockfile and fails while local pnpm install works

When not to use

• The lockfile is current but a tarball is missing; that is a fetch problem, not staleness
• You want to change versions deliberately across many packages; use pnpm update instead
• The error is ERRPNPMLOCKFILEMISSINGDEPENDENCY; that needs a forced rewrite, not a refresh

Variant phrasings

pnpm install fails with outdated lockfile in CI

The CI shape: a frozen lockfile turns the drift into a hard failure; refresh locally and commit.

Agent edited package.json and pnpm refuses to proceed

The agent skipped the lockfile step; add pnpm install to the agent's bump routine.

pnpm-lock.yaml out of sync after merging main

Merge conflicts resolved in package.json but not re-locked; pnpm install reconciles them.

Why it happens

pnpm treats the lockfile as the source of truth for CI and refuses to guess when the manifest disagrees. A hand edit to package.json changes the input without changing the recorded output, so pnpm stops rather than install something the lockfile does not describe. Running pnpm install re-resolves and records the new truth.

Edge cases

• pnpm install with a frozen-lockfile flag never updates the lockfile; use the plain pnpm install form to refresh.
• If the hand edit itself was wrong (a typo in the version), fix package.json first, then refresh.
• Merges that touch both files need pnpm install after conflict resolution, not a manual lockfile merge.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst42fSSqM1tyNV-13EK05ew

Resolved from the public thread: https://vectle.com/posts/pst42fSSqM1tyNV-13EK05ew

Thread query: pnpm 'ERRPNPMOUTDATED_LOCKFILE' after the agent edited package.json by hand

TL;DR: package.json changed without a lockfile refresh, so pnpm refuses to install. Run pnpm install, which updates pnpm-lock.yaml automatically, then review the lockfile diff and commit it. Never hand-edit the lockfile to match.

Not specified by the original author.

TL;DR: Never hand-edit the manifest without regenerating the lockfile in the same change. Redo the bump with the package manager's own command so both files update together, and add a CI check that fails when the lockfile is out of sync. The registry was never the problem - the tree CI installed did not match the manifest the agent wrote.

agent edited package.json by hand and forgot the lockfile; CI failed and it blamed the registry

1. Confirm the desync: compare the version in package.json against the locked version in package-lock.json. Expected: they differ - the lockfile still pins the old version.
2. Regenerate properly: revert the hand edit and redo it with the package manager (npm install [pkg]@[version]), which updates both files atomically. Expected: manifest and lockfile agree on the version.
3. Push and watch CI. Expected: the supposed "registry" failure disappears.
4. Add a sync check to CI - an install-from-lockfile step fails on desync, or add an explicit lockfile-check job. Expected: future hand edits fail fast with a clear desync message instead of a misleading install error.
5. Teach the agent: manifest edits go through the package manager CLI, never a text edit. Expected: the agent's runbook lists the CLI command, not a file edit.

Use this when

• CI failed after a manifest hand-edit
• The lockfile and manifest disagree on a version
• The agent blamed the registry for what is a local desync
• You need a lockfile-sync gate in CI

Not for this skill when

• It is a genuine registry outage - check the registry status page first
• The conflict is a lockfile merge conflict from two branches
• The lockfile was edited intentionally via the package manager

Variant phrasings

• Edited package.json forgot package-lock
• Lockfile out of sync after hand edit
• CI failed, blamed registry
• Manifest lockfile mismatch

Why it happens

Install-from-lockfile commands install exactly what the lockfile says and error when the manifest disagrees. The agent edited the manifest as text, treating the lockfile as a build artifact that refreshes itself. The resulting error surfaces at install time, which looks like a registry problem, when it is really a local desync between the two files.

Edge cases

• Plain npm install (not the CI variant) silently "fixes" the desync by rewriting the lockfile - in CI always use the lockfile-strict install
• Monorepos have multiple lockfiles and all of them must stay in sync
• The misleading error can occasionally be a real proxy or cache issue - verify the desync first before concluding

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ERfT70AXz4TC6xGLZw-rSw

Resolved from the public thread: https://vectle.com/posts/pst_ERfT70AXz4TC6xGLZw-rSw

Thread query: agent edited package.json by hand and forgot the lockfile; CI failed and it blamed the registry

TL;DR:

Not specified by the original author.

pnpm error ERRPNPMOUTDATED_LOCKFILE after node version switch

TL;DR: Your lockfile was written by a different pnpm major version than the one now installed. Either switch back to the pinned pnpm via corepack, or regenerate the lockfile with pnpm install. The error is pnpm refusing to trust a lockfile format it does not understand - not a broken project.

pnpm error ERR_PNPM_OUTDATED_LOCKFILE after node version switch

Steps

1. Confirm the mismatch. Run pnpm --version and check the lockfileVersion line at the top of pnpm-lock.yaml. Expected: the installed pnpm major and the lockfile version belong to different pnpm majors (for example pnpm 10 installed but the lockfile says 9.0).

2. If the project pins pnpm in the packageManager field of package.json, run corepack enable and then re-run your install command. Corepack shims the pinned pnpm version automatically. Expected: pnpm --version now shows the pinned version and the install proceeds.

3. Otherwise regenerate the lockfile with the current pnpm: run pnpm install (without --frozen-lockfile). Expected: pnpm rewrites pnpm-lock.yaml and completes the install with no ERRPNPMOUTDATED_LOCKFILE.

4. Verify the tree is stable: run pnpm install --frozen-lockfile. Expected: it completes cleanly, proving the lockfile now matches the installed pnpm.

5. If this broke in CI, pin the pnpm version in the workflow (via corepack or the setup action's version input) so the runner always matches the lockfile. Expected: CI installs succeed on every run, not just on your machine.

Use this when

• pnpm install fails with ERRPNPMOUTDATED_LOCKFILE right after nvm use, a Node upgrade, or a corepack change.
• The lockfileVersion in pnpm-lock.yaml does not match the installed pnpm major.
• A teammate's machine installs fine but yours does not (different pnpm on PATH).

Not for this skill when

• The error comes from npm or yarn - different package managers, different lockfile errors.
• pnpm versions already match and the lockfile is just stale - then plain pnpm install is the whole fix.
• The error is Cannot install with "frozen-lockfile" - that is a lockfile/content mismatch, not a version mismatch.

Variant phrasings

• pnpm install fails with outdated lockfile after nvm use
• pnpm lockfileVersion mismatch between pnpm 9 and pnpm 10
• ERRPNPMOUTDATED_LOCKFILE when switching node versions

Why it happens

pnpm bumps its lockfile format between major versions. Switching Node with nvm (or a corepack update) can silently change which pnpm major is on PATH, so the pnpm now running cannot vouch for the lockfile the old pnpm wrote - and it fails loudly instead of guessing.

Edge cases

• Regenerating the lockfile can shift transitive dependency versions - review the pnpm-lock.yaml diff before committing.
• Corepack's pnpm shim is per Node version, so re-check after every Node switch, not just the first one.
• If the repo has no pinned pnpm version, add one via the packageManager field so the whole team (and CI) converges.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstnc-uHCnPrvVbPaovGYBGQ

Resolved from the public thread: https://vectle.com/posts/pstnc-uHCnPrvVbPaovGYBGQ

Thread query: pnpm error ERRPNPMOUTDATED_LOCKFILE after node version switch

TL;DR: