Fix pnpx quick-start failure on pnpm 12.4.1 caused by transitive install scripts #566

Problem

The documented pnpx my-pi@latest command fails before the CLI starts on pnpm 12.4.1 because transitive dependencies have unapproved install scripts. Users should be able to follow the quick-start command without extra build-approval flags or global configuration changes.

Observed on Linux after updating pnpm with volta install pnpm@latest. The package resolved to my-pi@0.2.8.

Reproduction

With pnpm 12.4.1:

pnpx my-pi@latest

Installation fails with:

Error: ERR_PNPM_IGNORED_BUILDS
Ignored build scripts: @google/genai@1.52.0, esbuild@0.28.1, protobufjs@7.6.6
help: Run "pnpm approve-builds" to pick which dependencies should be allowed to run scripts.

The node-domexception@1.0.0 deprecation warning also appears, but is separate from this failure.

Investigation so far

• Cached pnpm 11.1.3 successfully ran pnpm dlx my-pi@0.2.8 --version, returning 0.2.8 with no explicit build approvals.
• pnpm 12.4.1 failed on the same my-pi release with the error above.
• Under 12.4.1, pnpx --allow-build=@google/genai --allow-build=esbuild --allow-build=protobufjs my-pi@latest --version completed the three dependency lifecycle scripts and returned 0.2.8.
• Adding those packages to allowBuilds in ~/.config/pnpm/config.yaml did not fix the plain command; those experimental entries were removed.
• These are transitive dependency lifecycle scripts, not my-pi's own build scripts.
• The inspected pnpm 11 implementation explicitly sets strictDepBuilds: false during dlx installation and provides an interactive approval flow. The inspected pnpm 12 implementation constructs a fresh build policy using the requested package and explicit --allow-build entries. This is a suspected pnpm behavior regression; its exact introduction and intended upstream behavior have not been established.
• Version-output checks confirm installation/CLI entry only; full TUI and provider functionality have not been tested in this comparison. The exact pnpm version active immediately before the update has not been independently established.

Source references: pnpm 11 dlx implementation, pnpm 12 dlx build policy.

Desired fix

Investigate a durable packaging/dependency fix so the documented command works on current pnpm. Requiring every user to append approval flags or downgrade pnpm should remain a temporary workaround.

• Trace which published runtime dependencies pull in the three script-bearing packages and determine which install steps are actually required.
• Evaluate dependency updates, removing unnecessary runtime dependencies, or bundling/prebuilding where appropriate. Preserve runtime loading, platform-specific binaries, and package licensing requirements.
• Track/report the pnpm behavior difference separately if needed; do not assume changing my-pi's own workspace approvals will affect consumers running pnpx.
• Add an isolated consumer-install smoke test against the packed release with current pnpm, including startup beyond --version where practical. Use a fresh cache so previously approved/prebuilt packages cannot hide failures.

Acceptance criteria

• A fresh install/start with the documented pnpx my-pi@latest requires no extra build-approval flags or user configuration on supported current pnpm.
• Runtime features affected by dependency or bundling changes are verified.
• Release validation catches this failure using the packed artifact, not only a workspace install.
• Document any remaining pnpm compatibility limitation and temporary workaround while a durable fix is pending.