GeezerVison

LLM Description written by Claude Code:claude-opus-5-5

Fixes #1514

Summary

On pnpm 11 and 12, a pnpm_config_trust_lockfile (or PNPM_CONFIG_TRUST_LOCKFILE) environment variable takes precedence over the trustLockfile: true that hosted mode writes into pnpm-workspace.yaml. If that variable was false, scan --mode hosted still wrote the key and reported "installs need no extra flags", and then every install in that environment failed with ERR_PNPM_TARBALL_URL_MISMATCH.

The scan now treats a non-true value of that variable as an explicit user setting, the same way it treats trustLockfile: false in the file and the way the npm arm treats npm_config_allow_remote. It writes nothing. The redirect_pnpm_trust_lockfile warning names the variable and gives the remedies: unset it, set it to true wherever the project installs, or re-run with --mode vendored.

Root cause

The trust plan in pnpm_trust (crates/socket-patch-core/src/hosted/engine.rs) chose between write, AlreadyTrue and UserSet by looking only at the text of pnpm-workspace.yaml. It never read the environment that pnpm 11+ reads ahead of that file.

Changes

• utils/pnpm_workspace.rs: new trust_lockfile_env(major, env). It returns the override only for pnpm 11 and newer, or when the major is unknown. pnpm 10 never verifies lock URLs, and no pnpm reads npm_config_trust_lockfile. The variable lookup goes through the existing env_setting. The pnpm-major heuristic is now one sync helper, pnpm_major_from, shared with the Hosted pnpm scan refuses with redirect_pnpm_lockfile_disabled over env lockfile settings the project's pnpm major ignores (e.g. any pnpm 11/12 project run through npm exec with package-lock=false) #1460 lockfile check.
• hosted/engine.rs: new RewriteOptions::pnpm_env, an injected environment lookup. The CLI passes the process env. The in-memory engine passes none, since it sees no install environment. pnpm_trust respects an override in both the root-workspace branch and the member-lock branch (Hosted scan from a pnpm 11/12 workspace member with its own lock writes trustLockfile into a nested member pnpm-workspace.yaml that pnpm ignores, so the root install fails with ERR_PNPM_TARBALL_URL_MISMATCH #880). The more specific pnpm 9.0–10.4 pin and keyless-members guidance still comes first.
• scan/hosted.rs: the member pre-check (redirect_pnpm_settings_elsewhere) no longer refuses with advice to add trustLockfile: true to the root file when the environment overrides that key. In that case the engine pins the member lock and reports the variable.
• Docs: CLI_CONTRACT.md (pnpm trust contract) and docs/ecosystems.md.

Test evidence

Run locally:

• cargo fmt --all -- --check: ok
• cargo clippy --workspace --all-features -- -D warnings: ok
• cargo test -p socket-patch-core --all-features --lib: 6484 passed. 4 failed, all of them read-only-permission tests (copy_tree::relax_loop_must_not_traverse_symlinked_root, vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, pypi_poetry::wire_write_failure_maps_error_and_leaves_lock_untouched, pypi_requirements::wire_failure_rolls_back_already_written_files). They can't fail as root, which is how the sandbox runs, and they are unrelated to this diff.
• cargo test -p socket-patch-cli --all-features --lib --bins: 920 passed
• e2e_redirect_pnpm_build -- --ignored pnpm11_: 4 passed
• The full cargo test --workspace build ran out of sandbox disk while linking the CLI integration binaries. CI covers those.
• No wrapper (npm/, pypi/, gem/) changes are needed: this is engine-only.

Review findings not fixed (/code-review high)

• pnpm_config_trust_lockfile=0 coercion. The value is read with the repo's existing env convention (PnpmSetting::as_bool, the npm-config reader: only ''/false/null/undefined are false), the same as every other pnpm env setting here. Changing that convention for one key would make them disagree.
• Uppercase spelling. Hosted pnpm 11/12 scan ignores a pnpm_config_trust_lockfile=false env override and says "installs need no extra flags", but the next frozen install fails with ERR_PNPM_TARBALL_URL_MISMATCH #1514 verified that PNPM_CONFIG_TRUST_LOCKFILE=false makes pnpm 12.11.2 fail on Linux, so it is honoured.
• A developer's shell env decides a committed file. This matches the npm npm_config_allow_remote precedent (CLI_CONTRACT), and the warning says plainly that nothing was written and why.
• Injected env vs std::env in view_setting. The injection keeps the engine testable and lets the in-memory engine opt out. Moving lockfile/gitBranchLockfile onto it is a separate refactor.

🤖 Generated with Claude Code

https://claude.ai/code/session_018Vu8yCCshtPxwd4jscWRAU

Generated by Claude Code