GitHub Actions · pnpm · Checked November 5, 2026

ERR_PNPM_OUTDATED_LOCKFILE in GitHub Actions: "Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date", and the Dependabot pull requests that cause it

In a CI environment, pnpm install runs as --frozen-lockfile when a lockfile is present: it does not write pnpm-lock.yaml, and it fails if the lockfile is out of sync with package.json (pnpm, install). GitHub Actions sets CI, so a lockfile that was not updated with its package.json stops the job at the install. The fix is almost always to update the lockfile and commit it, not to turn the check off. Since October 2026 a large share of these failures come from Dependabot pull requests that change a workspace package's package.json without the root lockfile.

What it looks like

ERR_PNPM_OUTDATED_LOCKFILE  Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with <ROOT>/package.json

Note that in CI environments this setting is true by default. If you still need to run install in such cases, use "pnpm install --no-frozen-lockfile"

  Failure reason:
  specifiers in the lockfile don't match specifiers in package.json:
* 2 dependencies are mismatched:
  - @xiboplayer/proxy (lockfile: 0.7.21, manifest: 0.7.22)
  - @xiboplayer/pwa (lockfile: 0.7.21, manifest: 0.7.22)

That is from xiboplayer-electron #116, where a tagged release had bumped two workspace packages without the lockfile. pnpm 12 prints the same reason in a boxed form ("× installing dependencies", then "Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with package.json"), and names the workspace project, such as in importers["."]. With pnpm/setup, which runs pnpm install by default, the error shows up in the setup step itself.

Reading the Failure reason

"specifiers in the lockfile don't match specifiers in package.json", followed by dependencies added, removed or mismatched: those package.json lines changed and the lockfile did not. The lockfile and manifest versions next to each name tell you which side is newer.
"the lockfile records importers["client"], but that project's directory or package.json is missing": the lockfile knows a workspace project that is not in the checkout or the image. This is the Docker case below.

The causes, and the fixes

A package.json changed without its lockfile

Someone edited package.json by hand, or a release script bumped versions, and pnpm-lock.yaml was not regenerated. Run pnpm install with the same pnpm version as CI and commit the lockfile. In a release script, run pnpm install --lockfile-only after the version bump and commit both files together.

Dependabot security updates to a workspace package

In a pnpm workspace, Dependabot's security updates for a package under apps/ or packages/ can change only that package's package.json and leave the root pnpm-lock.yaml as it was. Every job on the pull request then fails with ERR_PNPM_OUTDATED_LOCKFILE. This is an open bug (dependabot-core #16680): it was reported with pnpm 9.15.9, then confirmed on October 28 and 31, 2026, the second time with pnpm 12 and directory: "/", and on November 3 with a minimal reproduction on pnpm 12.11.2. One project saw the same with version updates under packages/* (ExaDev/trilean #71).

For each such pull request: check out its branch, run pnpm install --lockfile-only, and commit pnpm-lock.yaml to it. The CI run on the new commit then installs.
Changing the directories in dependabot.yml is not a reliable way around it; the October 31 report already had "/".

frozenLockfile in pnpm-workspace.yaml

If pnpm-workspace.yaml (or .npmrc) sets frozenLockfile: true, Dependabot cannot update the lockfile at all. Its updater runs pnpm install --lockfile-only, pnpm honours the setting from the file over environment variables (only a command-line flag overrides it, says the report), and every update in the job fails with dependency_file_not_resolvable, so no security pull request is opened (dependabot-core #16744; Renovate had the same). CI is already frozen by default, so remove the setting from the file, or pass --frozen-lockfile in the workflow's install step instead.

A Docker stage without a workspace package.json

A multi-stage Dockerfile that runs pnpm install --frozen-lockfile after copying only some files fails when the lockfile lists a workspace project whose package.json was not copied (caprover-app-template #12: stage 1 copied client/package.json, stage 2 did not). Copy pnpm-workspace.yaml, pnpm-lock.yaml and every workspace package.json before the install, or fetch from the lockfile alone with pnpm fetch and then install with pnpm install --offline. Pin the pnpm version in the image as well.

What not to do

pnpm install --no-frozen-lockfile in CI makes the job resolve again and pass, but what it installs is no longer what the committed lockfile says, and the lockfile it writes is thrown away with the runner.
--ignore-manifest-check skips the comparison with package.json; pnpm's documentation says to use it only when you just wrote the lockfile yourself.

Same pnpm in CI and on your machine

Pin pnpm in package.json with packageManager, for example "packageManager": "pnpm@12.16.1". Both pnpm/action-setup and pnpm/setup read it when no version input is given, and Vercel's build log shows it ("Detected `pnpm-lock.yaml` version 9 generated by pnpm@12.x from package.json#packageManager"). If the error appears only in CI, compare pnpm --version in the job with yours before you regenerate the lockfile.

Telling it apart

ERR_PNPM_LOCKFILE_CONFIG_MISMATCH: a setting that the lockfile records, such as overrides, differs from the configuration. Run pnpm install and commit the lockfile in the same way.
"Dependencies lock file is not found" from actions/setup-node: there is no pnpm-lock.yaml where setup-node looked.
"Unable to locate executable file: pnpm": pnpm is not installed before setup-node uses it.

See failed jobs from IntelliJ IDEA

Pipeline Inbox for GitHub Actions Workflows, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the runs of all your repositories in an IDE tool window, with their jobs and steps, so the Dependabot pull requests whose install failed stand out, and your current branch's runs are in the status bar. Reading is free; re-running failed jobs, cancelling, running workflows and reviewing deployments are Pro (US$1.50 a month, with a 30-day trial).

Get it on JetBrains Marketplace

GitHub, GitHub Actions and Dependabot are trademarks of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o.; Docker is a trademark of Docker, Inc.; Vercel is a trademark of Vercel Inc. This page is not affiliated with, sponsored or endorsed by any of them.

More: Unable to locate executable file: pnpm · Dependencies lock file is not found · GitHub Actions plugins for IntelliJ IDEA compared · 日本語