pnpm run fails when store is either read-only or network isolated

[ferbs]

Verify latest release

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

pnpm version

11.27.0

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

No response

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

No response

Reproduction steps

Run a package.json script (eg pnpm test or pnpm run local:prep) from within a sandbox, such as a docker container that mounts pnpm store as read only:
docker run -v /host/path/to/pnpm-store:/container/path/to/pnpm-store:ro etc...

And/or on an isolated network so long as pnpm thinks its state is dirty:
docker run --network my_isolated_bridge (or --network none)

Describe the Bug

All scripts in package.json script fail to run. Either with a failed network request or a failed attempt to modify read-only volume:

[ERR_SQLITE_ERROR] unable to open database file

[ERR_SQLITE_ERROR] unable to open database file

pnpm: unable to open database file
at file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:103725:19
at sqliteRetry (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:103635:14)
at StoreIndex.openDatabase (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:103724:9)
at new StoreIndex (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:103709:14)
at createNewStoreController (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:186188:83)
at async installDeps (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:225444:17)
at async Object.handler5 (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:226549:3)
at async file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:329570:19
at async main4 (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:329538:30)
at async runPnpm (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:329836:5)
[ERROR] Command failed with exit code 1: pnpm install

pnpm: Command failed with exit code 1: pnpm install
at getFinalError (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:90362:14)
at makeError (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:92669:21)
at getSyncResult (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:94514:10)
at spawnSubprocessSync (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:94474:14)
at execaCoreSync (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:94404:23)
at callBoundExeca (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:96932:23)
at boundExeca (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:96909:49)
at sync2 (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:97064:14)
at runPnpmCli (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:277638:5)
at runDepsStatusCheck (file:///home/coder/.nvm/versions/node/v24.21.0/lib/node_modules/pnpm/dist/pnpm.mjs:278854:7)

Related CLI options to bypass are not passed along: [ERROR] Unknown options: 'frozen-store', 'offline', 'frozen-lockfile'

Expected Behavior

Personally, I think run should not make any checks of pnpm state. In a monorepo, if install is required before say running a test, quite often other actions are also required, like building workspace dependencies, so automatic and required install doesn't offer much benefit.
If run must touch pnpm state by default, perhaps add a CLI option to bypass it?: --skip-all-fuckery

Which Node.js version are you using?

v24.21.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)

No response

[altaywtf]

I could reproduce both failures in Docker on 11.28.0, and the network one on 12.7.0.

Setup: a project with is-positive@1.0.0 and a hello script, installed in a node:24-bookworm-slim container with storeDir: /store. Then I deleted node_modules/.pnpm-workspace-state-v1.json so the state was dirty, and ran pnpm run hello in a new container:

• -v store:/store:ro: 11.28.0 fails with [ERR_SQLITE_ERROR] unable to open database file from the automatic pnpm install, and the script doesn't run. 12.7.0 runs the script.
• --network none: the automatic install stops at "Verifying lockfile against supply-chain policies". 11.28.0 was still waiting after 200 s. 12.7.0 fails after about 140 s with ERR_PNPM_RESOLVING_NPM_RESOLVER_NETWORK_ERROR for is-positive. The script doesn't run on either version, even though every package is already in node_modules and the store.
• Both flags together behave like --network none.

11.27.0 fails the same way.

Written by an agent (Claude Code, Opus 5.5).

[ferbs]

That case has to fail without network access in both versions

Scripts in package.json are used for a wide range of purposes, not just publish/install activities and should not require network access.

[Shuuren]

I'm working on a fix for this.

[ferbs]

Disabling verifyDepsBeforeRun seems to work, at least for an isolated network. in 11.27.0. I think its default shouldn't be install though.

[zkochan]

Well, this is not a bug. It works as expected today. I have converted it to a discussion.

[ferbs]

Sometimes the check is desirable, sometimes not, depending mostly on the target command/script. verifyDepsBeforeRun is too granular as a global, and it's currently too difficult to discover. There's no option or mention of it in pnpm run --help and no mention in the error message.

I'd suggest:

• most importantly: add a CLI switch to run that explicitly enables or disables the deps check
• mention the config option (and the new CLI option) in error messages
• change default for verifyDepsBeforeRun. Perhaps enable it for only built-in commands, or warn-on-failure rather than breaking user scripts unrelated to deps

[zkochan]

I don't think changing the default is an option at all. Other package managers are doing this by now as well and it is the behaviour users expect. There is an option to opt-out.

[zkochan]

closed by #16465