• Create PR with unit tests
• Commit unit tests in branch pq-run-for-all

Description

After delegating a resolving install to pacquet, writeEnvLockfile() restore failures are caught and
only logged, so the command can succeed while leaving pnpm-lock.yaml without the
env/configDependencies document. This can later break --frozen-lockfile installs and also prevents
pacquet identity verification from locating the declared configDependency via readEnvLockfile().

Code

installing/deps-installer/src/install/index.ts[R2099-2106]

+          if (envLockfile != null) {
+            await writeEnvLockfile(ctx.lockfileDir, envLockfile).catch((restoreErr: Error) => {
+              logger.warn({
+                error: restoreErr,
+                message: `Failed to restore the configDependencies document in pnpm-lock.yaml: ${restoreErr.message}`,
+                prefix: ctx.lockfileDir,
+              })
+            })

Evidence

The pacquet resolve path catches and warns on writeEnvLockfile() failure, allowing a successful
install to leave the lockfile without the env document. The env document is required for
configDependencies-related frozen installs, and pacquet verification depends on reading
configDependencies from readEnvLockfile().

installing/deps-installer/src/install/index.ts[2089-2107]
lockfile/fs/src/envLockfile.ts[59-76]
pnpm/test/install/configDeps.ts[23-34]
installing/commands/src/verifyPacquetIdentity.ts[82-92]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`writeEnvLockfile()` restore errors are currently swallowed (warn-only) after a successful pacquet resolving install. This can leave `pnpm-lock.yaml` missing the prepended env/configDependencies document while the install still exits 0, causing subsequent `--frozen-lockfile` installs to fail and preventing pacquet identity verification (which reads configDependencies from the env doc) from working reliably.
### Issue Context
The restore is meant to preserve pnpm’s multi-document lockfile env header across pacquet rewrites. If restore fails, the correct behavior is to fail the command (at least when pacquet itself succeeded), rather than leaving a silently-corrupted lockfile.
### Fix Focus Areas
- installing/deps-installer/src/install/index.ts[2095-2107]
### Suggested fix
Restructure the `try/finally` into `try/catch/finally` so you can distinguish whether pacquet succeeded.
- If pacquet succeeded and `writeEnvLockfile()` fails, throw (or wrap) the restore error so the install fails fast.
- If pacquet failed, attempt restore; if restore also fails, log the restore failure but rethrow the original pacquet error (or consider an `AggregateError` so both are visible).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

installInContext delegates to pacquet whenever runPacquet is set, without guarding
opts.lockfileCheck, so --check flows can end up doing a real install (and in resolve mode,
rewriting pnpm-lock.yaml). This violates the documented dry-run semantics used by commands like
pnpm dedupe --check.

Code

installing/deps-installer/src/install/index.ts[R2076-2108]

if (opts.runPacquet != null && !opts.lockfileOnly) {
+      // pacquet >= 0.11.7 resolves itself: hand it the whole install
+      // (resolve + fetch + import + link + build, writing the lockfile)
+      // in a single non-frozen pass. Only for plain installs — `add` /
+      // `update` / `remove` need pnpm to mutate the manifests and
+      // resolve the new specs first (pacquet's `install` reads
+      // package.json from disk, which pnpm hasn't rewritten yet).
+      if (opts.runPacquet.supportsResolution && !opts.frozenLockfile && allMutationsAreInstalls(projects)) {
+        // `configDependencies` are recorded in a YAML document prepended
+        // to `pnpm-lock.yaml` — purely a pnpm concept that pacquet doesn't
+        // model. Capture it before pacquet rewrites the lockfile and
+        // restore it afterwards (`writeEnvLockfile` re-reads pacquet's main
+        // document and re-prepends the env document), otherwise the next
+        // `--frozen-lockfile` install fails its config-deps freshness gate.
+        // The restore runs even if pacquet fails partway: a non-zero exit can
+        // still leave a rewritten lockfile behind, so the env document must be
+        // put back regardless.
+        const envLockfile = await readEnvLockfile(ctx.lockfileDir)
+        try {
+          await opts.runPacquet.run({ resolve: true })
+        } finally {
+          if (envLockfile != null) {
+            await writeEnvLockfile(ctx.lockfileDir, envLockfile).catch((restoreErr: Error) => {
+              logger.warn({
+                error: restoreErr,
+                message: `Failed to restore the configDependencies document in pnpm-lock.yaml: ${restoreErr.message}`,
+                prefix: ctx.lockfileDir,
+              })
+            })
+          }
+        }
+        return pacquetResolveResult(projects, ctx)
+      }

Evidence

dedupe --check routes through lockfileCheck specifically to avoid installing packages or editing
the lockfile. The core installer treats lockfileCheck as dry-run by skipping
linking/materialization and skipping lockfile writes, but the pacquet delegation branch does not
check lockfileCheck and can still run pacquet (including the new resolve-delegation path that
explicitly lets pacquet write pnpm-lock.yaml).

installing/commands/src/dedupe.ts[29-71]
installing/deps-installer/src/install/index.ts[1604-1622]
installing/deps-installer/src/install/index.ts[1852-1860]
installing/deps-installer/src/install/index.ts[2073-2108]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`lockfileCheck` is used as a non-mutating “check/dry-run” mode (no `node_modules` writes, no lockfile writes). The new pacquet delegation block in `installInContext` does not check `opts.lockfileCheck`, so pacquet can still be invoked and perform real install work.
## Issue Context
- `pnpm dedupe --check` explicitly sets `lockfileCheck` and documents that it should not install packages or edit the lockfile.
- The JS installer honors this by skipping linking/materialization and by skipping lockfile writes when `lockfileCheck` is present.
- The pacquet delegation block should follow the same rule and be disabled for `lockfileCheck` mode.
## Fix Focus Areas
- Guard pacquet delegation with `opts.lockfileCheck == null` (and likely also `opts.enableModulesDir`) so check-mode stays non-mutating.
- file/path references:
- installing/deps-installer/src/install/index.ts[2059-2119]
- installing/deps-installer/src/install/index.ts[1604-1605]
- installing/deps-installer/src/install/index.ts[1852-1853]
- installing/commands/src/dedupe.ts[29-71]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

After delegating a resolving install to pacquet, the code reloads the wanted lockfile via
readWantedLockfile() while still honoring useGitBranchLockfile/mergeGitBranchLockfiles. In
git-branch-lockfile mode this can reload an existing branch lockfile instead of the lockfile pacquet
just wrote, leaving ctx.wantedLockfile inconsistent with the materialized node_modules.

Code

installing/deps-installer/src/install/index.ts[R2120-2125]

+        const wantedLockfile = await readWantedLockfile(ctx.lockfileDir, {
+          ignoreIncompatible: opts.force || opts.ci === true,
+          mergeGitBranchLockfiles: opts.mergeGitBranchLockfiles,
+          useGitBranchLockfile: opts.useGitBranchLockfile,
+          wantedVersions: [LOCKFILE_VERSION],
+        })

Evidence

The pacquet resolve-delegation path reloads the wanted lockfile with git-branch-lockfile options
enabled; but the lockfile reader prefers the branch lockfile name first when configured, so pnpm can
reload a different file than the one pacquet wrote, causing state mismatch.

installing/deps-installer/src/install/index.ts[2082-2131]
lockfile/fs/src/read.ts[212-246]
lockfile/fs/src/lockfileName.ts[9-17]
installing/commands/src/runPacquet.ts[142-164]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The pacquet resolving-install path (`run({ resolve: true })`) refreshes `ctx.wantedLockfile` by calling `readWantedLockfile()` with `useGitBranchLockfile`/`mergeGitBranchLockfiles` options. In git-branch-lockfile mode, `readWantedLockfile()` prefers an existing branch lockfile over `pnpm-lock.yaml`, so pnpm may re-read a different file than the one pacquet just produced, leaving `ctx.wantedLockfile` stale/out-of-sync.

### Issue Context
- `readWantedLockfile()` tries the git-branch lockfile name first when `useGitBranchLockfile` is enabled.
- pacquet is spawned with `install` and no lockfile-name override, so pnpm must ensure it reloads the same file pacquet wrote.

### Fix Focus Areas
- installing/deps-installer/src/install/index.ts[2082-2131]
- installing/deps-installer/src/install/index.ts[391-411]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

installInContext delegates a resolving install to pacquet and then unconditionally reads
pnpm-lock.yaml, throwing if it is missing, but this branch does not check opts.useLockfile
("--no-lockfile"). This can either violate the no-lockfile contract (by creating a lockfile) or fail
the install with PACQUET_LOCKFILE_READ_FAILED if pacquet honors --no-lockfile and does not write
one.

Code

installing/deps-installer/src/install/index.ts[R2081-2127]

+    if (opts.runPacquet != null && !opts.lockfileOnly && opts.lockfileCheck == null && opts.enableModulesDir) {
+      // pacquet >= 0.11.7 resolves itself: hand it the whole install
+      // (resolve + fetch + import + link + build, writing the lockfile)
+      // in a single non-frozen pass. Only for plain installs — `add` /
+      // `update` / `remove` need pnpm to mutate the manifests and
+      // resolve the new specs first (pacquet's `install` reads
+      // package.json from disk, which pnpm hasn't rewritten yet).
+      if (opts.runPacquet.supportsResolution && !opts.frozenLockfile && opts.handleResolutionPolicyViolations == null && allMutationsAreInstalls(projects)) {
+        // `configDependencies` are recorded in a YAML document prepended
+        // to `pnpm-lock.yaml` — purely a pnpm concept that pacquet doesn't
+        // model. Capture it before pacquet rewrites the lockfile and
+        // restore it afterwards (`writeEnvLockfile` re-reads pacquet's main
+        // document and re-prepends the env document), otherwise the next
+        // `--frozen-lockfile` install fails its config-deps freshness gate.
+        // The restore runs even if pacquet fails partway: a non-zero exit can
+        // still leave a rewritten lockfile behind, so the env document must be
+        // put back regardless.
+        const envLockfile = await readEnvLockfile(ctx.lockfileDir)
+        let pacquetError: unknown
+        try {
+          await opts.runPacquet.run({ resolve: true })
+        } catch (err: unknown) {
+          pacquetError = err
+          throw err
+        } finally {
+          if (envLockfile != null) {
+            await writeEnvLockfile(ctx.lockfileDir, envLockfile).catch((restoreErr: Error) => {
+              if (pacquetError == null) {
+                throw restoreErr
+              }
+              logger.warn({
+                error: restoreErr,
+                message: `Failed to restore the configDependencies document in pnpm-lock.yaml: ${restoreErr.message}`,
+                prefix: ctx.lockfileDir,
+              })
+            })
+          }
+        }
+        const wantedLockfile = await readWantedLockfile(ctx.lockfileDir, {
+          ignoreIncompatible: opts.force || opts.ci === true,
+          mergeGitBranchLockfiles: opts.mergeGitBranchLockfiles,
+          useGitBranchLockfile: opts.useGitBranchLockfile,
+          wantedVersions: [LOCKFILE_VERSION],
+        })
+        if (wantedLockfile == null) {
+          throw new PnpmError('PACQUET_LOCKFILE_READ_FAILED', `pacquet did not write a readable ${WANTED_LOCKFILE}`)
+        }

Evidence

The pacquet resolving branch runs without any opts.useLockfile check and then requires a readable
wanted lockfile, while the installer options explicitly support disabling lockfile generation via
useLockfile (only lockfileOnly forbids it).

installing/deps-installer/src/install/index.ts[2078-2127]
installing/deps-installer/src/install/extendInstallOptions.ts[356-430]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The pacquet resolve-delegation path assumes `pnpm-lock.yaml` exists after `run({ resolve: true })` and throws if it doesn’t. This is incompatible with `useLockfile=false` / `--no-lockfile` installs.
### Issue Context
`extendInstallOptions` supports turning lockfiles off (`useLockfile=false`). In that mode, the installer should not require a wanted lockfile to exist, nor should it error because it’s missing.
### Fix Focus Areas
- installing/deps-installer/src/install/index.ts[2081-2127]
Suggested implementation direction:
- Add an explicit guard to the pacquet resolving-delegation branch so it only runs when lockfiles are enabled and expected to be written, e.g. require `opts.useLockfile && opts.saveLockfile` in the `supportsResolution` condition.
- Alternatively (if you want to support pacquet resolving installs without a lockfile), skip `readWantedLockfile(...)`/`PACQUET_LOCKFILE_READ_FAILED` and return an `InstallFunctionResult` that does not assume a lockfile exists; but this likely requires additional downstream adjustments, so the safe fix is to not delegate in no-lockfile mode.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In the pacquet resolving-install path, pnpm returns an InstallFunctionResult with
resolutionPolicyViolations hard-coded to [], so policy violations discovered during resolution are
not surfaced to the commands layer. This prevents policy UX/persistence like
minimumReleaseAgeExclude auto-collect (and any future policy-driven workspace-manifest updates),
risking later install failures when pnpm re-validates the lockfile outside the pacquet resolve path.

Code

installing/deps-installer/src/install/index.ts[R1948-1957]

+function pacquetResolveResult (projects: ImporterToUpdate[], ctx: PnpmContext): InstallFunctionResult {
+  return {
+    newLockfile: ctx.wantedLockfile,
+    projects: projects.map((project) => ({
+      manifest: project.originalManifest ?? project.manifest,
+      rootDir: project.rootDir,
+    })),
+    depsRequiringBuild: [],
+    resolutionPolicyViolations: [],
+  }

Evidence

The pacquet resolve path returns pacquetResolveResult(...), which hard-codes an empty
resolutionPolicyViolations array. The install command uses resolutionPolicyViolations to derive
and persist policy updates like minimumReleaseAgeExclude, so this new behavior suppresses those
updates and associated UX.

installing/deps-installer/src/install/index.ts[2069-2127]
installing/deps-installer/src/install/index.ts[1939-1958]
installing/deps-installer/src/install/index.ts[1519-1539]
installing/commands/src/installDeps.ts[407-465]
installing/commands/src/policyHandlers.ts[139-196]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
When pacquet performs a resolving install (`runPacquet.run({ resolve: true })`), pnpm returns `pacquetResolveResult(...)`, which currently hard-codes `resolutionPolicyViolations: []`. The commands layer relies on `resolutionPolicyViolations` to drive policy UX and persistence (e.g. minimumReleaseAge strict prompting / auto-persisting `minimumReleaseAgeExclude`), so this path silently suppresses that behavior.
### Issue Context
- The resolving pacquet path returns early from `installInContext` and bypasses pnpm’s normal `resolveDependencies(...)` flow (where `handleResolutionPolicyViolations` is applied and violations are collected).
- Downstream code uses the returned `resolutionPolicyViolations` to update workspace policy state (e.g. write `minimumReleaseAgeExclude` entries).
### Fix Focus Areas
- installing/deps-installer/src/install/index.ts[1939-1957]
- installing/deps-installer/src/install/index.ts[2078-2127]
- installing/deps-installer/src/install/index.ts[1519-1539]
### Suggested fix approach
Pick one of these (A is simplest/most correct wrt strict-mode prompting):
**A) Don’t delegate resolve to pacquet when policy UX/persistence is active**
- In the `supportsResolution && !opts.frozenLockfile && allMutationsAreInstalls(...)` branch, add a guard that disables the `resolve:true` delegation when pnpm policy handling is active (e.g. `opts.handleResolutionPolicyViolations` is set and/or policy-related opts like `minimumReleaseAge` are present).
- Fall back to the existing pnpm resolve-then-materialize flow in that case so pnpm can collect violations and prompt/persist before side effects.
**B) Reconstruct and return violations after pacquet resolves**
- After reading the lockfile written by pacquet, compute `resolutionPolicyViolations` for the new lockfile (using the same verifier chain) and return them instead of `[]`.
- If `opts.handleResolutionPolicyViolations` exists, invoke it with the collected violations (note: strict-mode prompting after pacquet has already mutated state is likely unacceptable, so still consider gating strict mode back to A).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

After delegating a resolving install to pacquet (resolve:true), pnpm never reloads the lockfile that
pacquet just rewrote, so ctx.wantedLockfile remains the pre-install snapshot. Post-install logic
that iterates ctx.wantedLockfile.packages (e.g. revoked build-approval detection) can therefore run
against the wrong package set and produce incorrect ignoredBuilds results/logs.

Code

installing/deps-installer/src/install/index.ts[R2093-2108]

+        const envLockfile = await readEnvLockfile(ctx.lockfileDir)
+        try {
+          await opts.runPacquet.run({ resolve: true })
+        } finally {
+          if (envLockfile != null) {
+            await writeEnvLockfile(ctx.lockfileDir, envLockfile).catch((restoreErr: Error) => {
+              logger.warn({
+                error: restoreErr,
+                message: `Failed to restore the configDependencies document in pnpm-lock.yaml: ${restoreErr.message}`,
+                prefix: ctx.lockfileDir,
+              })
+            })
+          }
+        }
+        return pacquetResolveResult(projects, ctx)
+      }

Evidence

The resolve-delegation branch runs pacquet with resolve:true and immediately returns a result that
uses ctx.wantedLockfile without re-reading the rewritten lockfile. The same function later
performs post-install checks that iterate ctx.wantedLockfile.packages, so those checks will
observe stale data after a pacquet-resolved install.

installing/deps-installer/src/install/index.ts[2073-2108]
installing/deps-installer/src/install/index.ts[1936-1956]
installing/deps-installer/src/install/index.ts[477-516]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
In the pacquet resolve-delegation path (`await opts.runPacquet.run({ resolve: true })`), pacquet rewrites `pnpm-lock.yaml`, but pnpm does not refresh `ctx.wantedLockfile` afterward and returns `pacquetResolveResult(projects, ctx)`.
Later, `mutateModules()` runs post-install checks that iterate `ctx.wantedLockfile.packages`, which will still reflect the old lockfile contents, not the one pacquet just wrote.
## Issue Context
- The resolve-delegation path intentionally lets pacquet write `pnpm-lock.yaml`.
- pnpm keeps using the previously-loaded `ctx.wantedLockfile` object after delegation.
## Fix Focus Areas
- installing/deps-installer/src/install/index.ts[2073-2108]
- installing/deps-installer/src/install/index.ts[1936-1956]
- installing/deps-installer/src/install/index.ts[477-516]
## Suggested fix
1. After the pacquet run (and after restoring the env document), re-read the updated lockfile from disk and update `ctx.wantedLockfile` to the on-disk content (main document).
2. Return that freshly read lockfile in the `InstallFunctionResult` (either by passing it into `pacquetResolveResult` or by setting `newLockfile` to the re-read value), so any downstream logic uses the correct snapshot.
3. If re-reading fails (e.g. pacquet crashed before writing a valid main document), decide on a safe fallback: keep the old lockfile but skip post-install checks that require an up-to-date package list (or surface a warning).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In the pacquet resolve-delegation path, the env/configDependencies YAML document is only restored
after a successful pacquet run; if pacquet exits non-zero after rewriting pnpm-lock.yaml, pnpm
throws before calling writeEnvLockfile(). This can leave pnpm-lock.yaml missing the env document and
break subsequent installs that rely on configDependencies freshness checks.

Code

installing/deps-installer/src/install/index.ts[R2039-2043]

+        const envLockfile = await readEnvLockfile(ctx.lockfileDir)
+        await opts.runPacquet.run({ resolve: true })
+        if (envLockfile != null) {
+          await writeEnvLockfile(ctx.lockfileDir, envLockfile)
+        }

Evidence

The delegation path captures the env doc and restores it only after pacquet completes; however, the
pacquet runner throws on non-zero exit, which skips the restore call, and writeEnvLockfile is the
mechanism that re-prepends the env document to the lockfile.

installing/deps-installer/src/install/index.ts[2033-2043]
installing/commands/src/runPacquet.ts[185-194]
lockfile/fs/src/envLockfile.ts[59-76]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
When delegating a resolving install to pacquet, pnpm captures the env lockfile document before running pacquet and restores it afterward. If pacquet fails (throws), the restore step is skipped, potentially leaving `pnpm-lock.yaml` without the prepended env/configDependencies document.
## Issue Context
- `opts.runPacquet.run({ resolve: true })` throws on non-zero exit.
- The env doc restoration is currently only executed on the success path.
## Fix
Ensure the env lockfile document restoration is attempted in a `finally` block (or equivalent), without masking the original pacquet error:
- Capture `envLockfile` before invoking pacquet.
- `try { await runPacquet(...) } catch (e) { savedError = e } finally { if (envLockfile) { try { await writeEnvLockfile(...) } catch (restoreErr) { /* log warn; don't override savedError */ } } }`
- Re-throw the original pacquet error if present.
## Fix Focus Areas
- installi...