pnpm install and non-install commands disagree on @pnpm/exe in packageManagerDependencies, lockfile flip-flops forever #14575

Verify latest release

• I verified that the issue exists in the latest pnpm release (12.3.4)

pnpm version

12.3.4

Which area(s) of pnpm are affected? (leave empty if unsure)

Lockfile, CLI

Reproduction steps

Minimal project, no dependencies — only the pin (devEngines or packageManager, both reproduce):

{
  "name": "pnpm-exe-repro",
  "private": true,
  "devEngines": {
    "packageManager": { "name": "pnpm", "version": "12.3.4", "onFail": "download" }
  }
}

$ pnpm i --lockfile-only
$ grep -c "@pnpm/exe@" pnpm-lock.yaml
0
$ pnpm list
$ grep -c "@pnpm/exe@" pnpm-lock.yaml
2
$ pnpm i --lockfile-only
$ git diff --stat pnpm-lock.yaml
# empty — byte-identical to the first install

The block added by pnpm list (+19 lines): an '@pnpm/exe' entry under packageManagerDependencies, plus the @pnpm/exe@12.3.4 entries under packages: and snapshots:. Reproduces with pnpm exec … too, and with "packageManager": "pnpm@12.3.4" instead of devEngines.

Describe the Bug

The install pipeline and the pre-command syncEnvLockfile path disagree on the content of the env document: install records only pnpm, while any non-install command (list, exec, …) additionally records the running executable as @pnpm/exe. Alternating the two commands flips the same 19 lines back and forth indefinitely, so the lockfile is never stable and every other command dirties the tree.

Expected Behavior

Both paths converge on one representation — either both record @pnpm/exe or neither does — so a read-only command like pnpm list never dirties pnpm-lock.yaml after an up-to-date install.

Related

• pacquet: packageManagerDependencies are synced only by install commands, not by every command as in pnpm #13348 — every command syncing packageManagerDependencies is intended; this issue is that the two sync sites disagree on content.
• Use the hardened lockfile writer for env document updates #14322 — env and project documents go through different write paths.
• --frozen-lockfile silently rewrites packageManagerDependencies instead of failing with ERR_PNPM_OUTDATED_LOCKFILE #14009 / pnpm 12 ERR_PNPM_FROZEN_LOCKFILE_WITH_OUTDATED_LOCKFILE #14124 — prior packageManagerDependencies vs --frozen-lockfile bugs in the same block.

Which Node.js version are you using?

v26.1.0

Which operating systems have you used?

• macOS
• Windows
• Linux