pnpm 11.0.5: why you should check `dlx`, `create`, and self-update on Intel Mac

pnpm just updated, and dlx may behave differently now

pnpm 11.0.5 and the companion pnpm 10.33.3 are not cosmetic patches. They change behavior in two zones where errors silently break developer bootstrap and CI: packages run through pnpm dlx / pnpm create with transitive install scripts, and self-update on Intel macOS. If your team runs pnpm 10 or 11, it’s better to check these scenarios ahead of time rather than hunting down a weird Monday morning failure.

What happened

pnpm 11.0.5

Release 11.0.5 brought several changes that affect real-world workflows:

1. Changed behavior in pnpm dlx and pnpm create — these commands now handle transitive install scripts differently. If a package you run through dlx pulls in a dependency with a postinstall / install script, pnpm now requires explicit permission via approve-builds.
2. Better cleanup after failed installs — if an installation fails, pnpm cleans up after itself more thoroughly. This matters in CI, where dirty node_modules states lead to false positives or negatives.
3. Explicit build script permissions — the approve-builds mechanism now more precisely tracks which packages are allowed to run build scripts. This is controlled via onlyBuiltDependencies / ignoredBuiltDependencies in package.json.

pnpm 10.33.3

The parallel patch 10.33.3 addresses self-update on Intel macOS. If anyone on your team still uses an Intel MacBook and updates pnpm via pnpm self-update, the removed darwin-x64 artifact from @pnpm/exe could leave them without a working package manager.

Why this matters

Three common scenarios where things can break:

1. Project generators via pnpm create

Many popular templates (create-vite, create-next-app, create-svelte, and others) use pnpm create. If such a generator or one of its transitive dependencies has an install / postinstall script, pnpm 11 may stop and ask for explicit permission. On a local machine it’s just an annoying prompt. In CI — it’s a failed pipeline.

2. One-shot CLI tools via pnpm dlx

Commands like pnpm dlx @some/tool --init often live in onboarding scripts or Makefiles. If @some/tool pulls in a dependency with a build script, pnpm 11 may behave differently than pnpm 10. And that “differently” isn’t always an obvious error message.

3. Intel macOS — the self-update trap

pnpm 10.33.3 officially confirms: the darwin-x64 binary artifact has been removed from @pnpm/exe. If someone on Intel Mac uses pnpm self-update — pnpm will simply stop finding a new version for their architecture. Not “it crashes,” but silently fails to update. That’s worse — at least an explicit error shows something is wrong.

How to check your scripts in 20 minutes

Step 1 — Check pnpm version

pnpm -v

If you’re on pnpm 11.x — you’re exposed to the dlx / create changes. Even on 10.x, it’s worth checking before your planned upgrade to 11.

Step 2 — Find all dlx / create calls in your codebase

# Search in Makefiles, CI configs, scripts
grep -rn "pnpm dlx\|pnpm create" Makefile .github/ scripts/ .ci/ 2>/dev/null

Don’t forget to check:

• Makefile
• .github/workflows/*.yml
• Jenkinsfile or docker-compose scripts
• onboarding docs (README.md, CONTRIBUTING.md)
• local aliases in .zshrc / .bashrc on your team’s build server

Step 3 — Audit approve-builds

Open package.json and find the pnpm section:

{
  "pnpm": {
    "onlyBuiltDependencies": ["esbuild", "sharp"],
    "ignoredBuiltDependencies": ["bufferutil"]
  }
}

Rule: every package that has an install script and is used (even transitively) must be either in onlyBuiltDependencies or in ignoredBuiltDependencies. If pnpm complains about inconsistency — that’s your signal.

Run:

pnpm approve-builds

This command interactively shows which packages have build scripts and lets you add them to the correct list. For CI, you can run with --allow-build for each package you know and trust.

Step 4 — Test dlx locally

Run every pnpm dlx / pnpm create you found in step 2:

pnpm dlx create-vite@latest test-project --template vanilla
# Check that it completes without an approve-builds prompt
rm -rf test-project

If the command stops and asks for permission — you’ve found a problem before it hits CI.

Step 5 — Intel Mac self-check

For developers on Intel Mac:

uname -m
# Should return x86_64

# Check how pnpm is installed
which pnpm
# If the path goes through ~/.local/share/pnpm or @pnpm/exe — pay attention

If pnpm is installed via @pnpm/exe (a separate npm package with a binary) — pnpm self-update will no longer work on Intel. The fix: reinstall pnpm globally via npm:

npm install -g pnpm

This universal method works across all architectures.

What NOT to do (common mistakes)

Don’t ignore approve-builds in CI

The temptation is to breeze through approve-builds interactively, throw everything into ignoredBuiltDependencies, and forget about it. That solves the immediate problem but creates a security risk: any new package with an install script automatically gets permission to run during pnpm install.

The right approach: use onlyBuiltDependencies — an explicit whitelist, not blanket ignore.

Don’t upgrade pnpm in CI without local testing

If your team moved to pnpm 11.0.5 and someone pushes — CI might break due to the new dlx behavior. Simple rule: pnpm upgrade = locally run all pnpm dlx / pnpm create = then CI.

Don’t rely on pnpm self-update on Intel Mac

It won’t work anymore. If someone on your team is still on Intel — that’s not an edge case, that’s a real person who won’t be able to update before tomorrow’s standup.

Don’t skip transitive dependencies

Even if your direct package has no install scripts — its transitive dependency might. And pnpm 11 checks for this.

# Find packages with install scripts in the tree
pnpm ls --recursive | while read pkg; do
  node -e "try{let p=require('$pkg/package.json'); if(p.scripts?.install||p.scripts?.postinstall) console.log('$pkg has install script')}catch{}"
done

Team checklist

Here’s a minimal checklist you can add to team documentation or onboarding:

1. Version: make sure everyone on the team is on the same major pnpm version (pnpm -v).
2. dlx/create smoke test: run pnpm dlx create-vite@latest — should work without a prompt.
3. approve-builds audit: check package.json → pnpm.onlyBuiltDependencies.
4. Intel Mac: if applicable — reinstall via npm: npm install -g pnpm.
5. CI pipeline: add pnpm approve-builds --allow-build <package> to the build script for each known package with an install script.
6. README: document the pnpm version and a minimal smoke test for new team members.

Conclusion

pnpm 11.0.5 is an important update from a security and reliability standpoint, but it changes the rules for dlx/create workflows and self-update on Intel Mac. The check takes 20–30 minutes and saves your CI from unexpected failures.

If you want a deeper audit — try the Prompt Pack below, fill in your data, and get a structured risk analysis for your team.