Lockfile policy error message tells users to relax policy for unexpected changes #14411

Verify latest release

• I verified that the issue exists in the latest pnpm release

pnpm version

11.25.0

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

Lockfile

Link to the code that reproduces this issue or a replay of the bug

No response

Reproduction steps

$ mkdir z && cd z

$ pnpm add express-rate-limit@8.2.2

$ echo "trustPolicy: 'no-downgrade'" > pnpm-workspace.yaml

$ pnpm install
? Verifying lockfile against supply-chain policies (68 entries)...
Lockfile is up to date, resolution step is skipped
Already up to date
✗ Lockfile failed supply-chain policy check (68 entries in 479ms)
[ERR_PNPM_TRUST_DOWNGRADE] 1 lockfile entries failed verification:
  express-rate-limit@8.2.2 High-risk trust downgrade for "express-rate-limit@8.2.2" (possible package takeover)

The lockfile contains entries that the active policies reject. This can mean the lockfile is stale, or that someone committed a lockfile that bypassed the policy locally — inspect recent changes to pnpm-lock.yaml before trusting it. If the changes look expected, run "pnpm clean --lockfile" and then "pnpm install" to rebuild from a fresh resolution. Alternatively, relax the policy that flagged them.

Describe the Bug

The error message above tells users to relax the policy when pnpm-lock.yaml contains unexpected changes, allowing installation of the dependency pnpm just identified as a possible takeover.

Analyzing the English in the error message:

1. It first tells users to inspect pnpm-lock.yaml, but provides a recovery action only for "expected changes":

   If the changes look expected, run "pnpm clean --lockfile" and then "pnpm install" ...

2. It continues with "Alternatively", meaning "after unexpected changes", recommending users relax the policy that flagged them:

   Alternatively, relax the policy that flagged them.

The error message is defined in both:

1. TypeScript verifier
2. Rust verifier

Expected Behavior

The error message should suggest changing the policy only after:

1. expected changes have been rebuilt from a fresh resolution
2. and the user trusts the affected packages

For example:

The lockfile contains entries that the active policies reject. This can mean the lockfile is stale, or that someone committed a lockfile that bypassed the policy locally — inspect recent changes to pnpm-lock.yaml before trusting it. If the changes look expected, run "pnpm clean --lockfile" and then "pnpm install" to rebuild from a fresh resolution. If the fresh resolution still fails and you trust the affected packages, relax the policy that flagged them.

Which Node.js version are you using?

v24.13.0

Which operating systems have you used?

• macOS
• Windows
• Linux

If your OS is a Linux based, which one it is? (Include the version if relevant)

No response