Read-only and rejected commands unexpectedly create package.json in directories without a manifest #16907

Verify latest release

• I verified that the issue exists in the latest pnpm release

pnpm version

No response

Which area(s) of pnpm are affected? (leave empty if unsure)

CLI

Link to the code that reproduces this issue or a replay of the bug

No response

Reproduction steps

Run outside any existing project or workspace:

cd "$(mktemp -d)"

pnpm --version
pnpm rt ls
cat package.json

The runtime command exits with status 1:

Error: ERR_PNPM_RUNTIME_UNKNOWN_SUBCOMMAND

  × Unknown subcommand: ls

Nevertheless, package.json now exists and contains the default initialization template, including version 1.0.0, the placeholder test script, and license ISC.

Describe the Bug

Several commands create a default package.json merely while initializing command state, including read-only queries and invocations that subsequently fail argument or prerequisite validation.

For example, pnpm rt ls correctly reports ERR_PNPM_RUNTIME_UNKNOWN_SUBCOMMAND, but leaves a newly created package.json in the working directory.

This is broader than the runtime command. Successful queries and dedupe --check are also affected.

Other affected commands

Run each command in a separate fresh empty directory.

Results below are from 12.11.2. Every row creates package.json.

There is also a successful lockfile-only reproduction:

cd "$(mktemp -d)"

cat > pnpm-lock.yaml <<'YAML'
lockfileVersion: '9.0'

settings:
  autoInstallPeers: true
  excludeLinksFromLockfile: false

importers:
  .: {}
YAML

pnpm fetch
cat package.json

Both tested v12 releases create package.json, although fetch is documented as ignoring the package manifest.

Starting again with only the same lockfile and running pnpm sbom --sbom-format cyclonedx also succeeds and creates the manifest. The generated SBOM then includes the scaffold's directory-derived name, version 1.0.0, and license ISC as root component metadata.

Suspected cause

In v12.11.2, State::load_or_create_manifest falls through to PackageManifest::create_if_needed outside a workspace. That function immediately writes the scaffold.

The runtime dispatcher initializes this state before validating the runtime subcommand. Several query commands use the same state initialization.

dedupe --check restores or removes the lockfile through its guard, but the newly created manifest remains.

link has a separate call to create_if_needed() before resolving the target manifest. Consequently, link ./missing also creates a root manifest in a workspace containing only pnpm-workspace.yaml with packages: [].

Scope and related work

PR #12919 already prevents the shared state initializer from scaffolding manifests inside workspaces. It does not cover ordinary non-workspace directories, and link bypasses that guard.

PR #12910 previously fixed scaffolding over an existing alternate manifest.

In the tested existing-manifest controls, JSON, JSON5, and YAML manifests remained unchanged. Commands such as list, licenses list, and rt --help did not create a manifest.

A fix likely needs to separate loading command state from persisting a new manifest, and also address link independently. Moving runtime validation earlier would fix the original reproduction but leave the successful read-only cases affected.

Regression coverage should include missing manifests outside workspaces, the rootless-workspace link case, and lockfile-only fetch/sbom, while preserving intentional manifest creation by commands that explicitly initialize or modify a package.

Expected Behavior

• Read-only queries and check mode should not create a project manifest.
• Invalid arguments and missing prerequisites in these examples should be rejected before creating a manifest.
• Fetching from a lockfile should not initialize a package.
• SBOM generation should not invent package metadata by persisting an initialization template.

Which Node.js version are you using?

24.20.0

Which operating systems have you used?

• macOS
• Windows
• Linux

If your OS is a Linux based, which one it is? (Include the version if relevant)

Fedora

Contributing a fix

• I am working on a fix