feat: Phase 1 of `allowScripts` opt-in install-script policy by JamieMagee · Pull Request #9360 · npm/cli

JamieMagee · 2026-05-15T03:38:09Z

Implements Phase 1 of npm/rfcs#868, which makes dependency install scripts opt-in.

Install behaviour is unchanged. Scripts still run as they always have. The only Phase 1 user-visible change is one advisory block at the end of npm install listing packages whose install scripts haven't been reviewed via the new allowScripts field in package.json. A future release will turn that advisory into an actual block.

What landed

allowScripts field in package.json, read at install time
Three new configs: allow-scripts, strict-script-builds, dangerously-allow-all-scripts. The latter two are no-ops in this release. They're registered so projects can pin them in tooling ahead of the release that flips the default.
npm approve-scripts and npm deny-scripts commands, with the RFC's asymmetric pin rule (approves can pin, denies are always name-only)
Advisory warning during npm install, ci, update, and rebuild. npm exec / npx consult only the user/global .npmrc layer per the RFC, with the policy threaded through libnpmexec for Phase 2 enforcement.
Identity matcher in @npmcli/arborist covering registry, git, file, and remote tarballs. Registry identity is derived from the lockfile's resolved URL (via versionFromTgz), never from node.packageName or node.version. Those getters read the installed tarball's package.json and can be forged.
Aliases match against the underlying registered package, not the alias name. trusted@npm:[email protected] is approved by writing naughty, not trusted. Holds even under omitLockfileRegistryResolved, where the install location alone (node_modules/trusted) would be misleading. The underlying name is derived from the incoming edge's alias subSpec.
Bundled deps with install scripts are flagged as unreviewed and filtered out of npm approve-scripts --all and positional matches. Per RFC they cannot be allowlisted in Phase 1.
Warning when a non-root workspace declares its own allowScripts

What's deliberately deferred

Actual blocking. The matcher exists and the policy is threaded through to arborist, but arb.rebuild()'s build set still runs everything. Phase 2 will gate #addToBuildSet on the matcher.
A safe allowlist syntax for bundled deps. The RFC notes a candidate [email protected] > bundled-name form for a follow-up.

Refs: npm/rfcs#868

bakkot · 2026-05-15T23:24:17Z

I think it would be bad to support an allowScripts field which can contain "foo": false but still allow foo's scripts to run. Similarly I think it would be bad to include a no-op strict-script-builds. That looks like it provides protection, but doesn't.

Also, it's weird to print this advisory information without it being actionable (except by silencing the warning).

I think a better phasing would be to implement the full RFC except that the default for packages not explicitly listed is to allow with warning, rather than to deny with warning, and then a later release can make the default to deny with warning and make no other changes.

If you really don't want to implement blocking in the first phase, it would be better for it to be a hard error to have "foo": false in allowScripts.

Three new configs: allow-scripts, strict-script-builds, dangerously-allow-all-scripts.

Why is the --allow-scripts CLI flag necessary? I feel like that's just going to encourage people to say "install this with npm install foo --allow-scripts=foo" and then it will work on their machine but not for the next person who tries to build the package.

Also, sidebar, the naming of strict-script-builds and dangerously-allow-all-scripts is weird. I would expect those to be named similarly, or possibly be the same option (--enforce-allow-scripts=on vs --enforce-allow-scripts=dangerously-off, maybe).

JamieMagee · 2026-05-17T00:11:53Z

@bakkot Yeah, all of that sounds good. I'll switch to your proposed phasing.

Concretely:

Actual enforcement goes in. true allows, false blocks, both do what the user expects.
Phase 1 default for unlisted packages stays "allow with warning", which keeps the RFC's promise that nothing changes for anyone who hasn't opted in. Phase 2 is then the default flip.
Renaming --strict-script-builds to --strict-allow-scripts. --dangerously-allow-all-scripts keeps its name. I'd rather have a long, ugly, obviously discouraged flag than collapse it into a ternary.
Going to tighten the --allow-scripts description too, calling out that it's for one-off / npx use and that team-wide policy belongs in package.json or .npmrc. Doesn't remove the footgun but at least doesn't lean into it.

The reason I shipped advisory-only originally was to keep the "install behaviour unchanged" promise in the RFC. Your phasing keeps that for everyone who doesn't write a false entry, and anyone who does is opting in deliberately. Better than what I had.

Going to amend the RFC for the new phasing and update the PR description here.

bakkot · 2026-05-17T00:36:05Z

SGTM.

Renaming --strict-script-builds to --strict-allow-scripts. --dangerously-allow-all-scripts keeps its name. I'd rather have a long, ugly, obviously discouraged flag than collapse it into a ternary.

I don't feel strongly about this point, but fwiw --enforce-allow-scripts=dangerously-off is in fact longer and more ugly than --dangerously-allow-all-scripts, and is at least as obviously discouraged to my eye.

That said, it's true that there are two dangerous things (the [new] phase 1 default, and disabled entirely), and naming both would be a little awkward. Best I've got is --enforce-allow-scripts=dangerously-allow-missing and --enforce-allow-scripts=dangerously-off respectively.

…low-all-scripts configs Three new configs to support the install-script opt-in policy. None of them affect install behaviour yet; they're read by approve-scripts, deny-scripts, and the install-time walker in later commits. - allow-scripts: comma-separated package list. Used as a fallback when the root package.json has no allowScripts field. Flattens to flatOptions.allowScripts. - strict-script-builds: boolean. Reserved for a future release that will turn blocked-script warnings into errors. No-op for now. - dangerously-allow-all-scripts: boolean escape hatch for that same future release. No-op for now. Refs: npm/rfcs#868

…I configs A precedence resolver reads the install-time allowScripts policy from the layered sources and threads it through install/ci into arborist. - lib/utils/resolve-allow-scripts.js: pure resolver. Reads from npm.prefix so workspace sub-installs still pick up the project root. Returns { policy, source }. Strict fallback: package.json wins over flat config; lower layers are silently ignored, with one warn when a lower setting is being suppressed. - install.js / ci.js: await the resolver before constructing arborist opts, then pass policy through opts.allowScripts. Add the three new params to each command's static params list. - workspaces/arborist/lib/arborist/index.js: accept options.allowScripts and store it on this.options. No enforcement yet; read in later commits. Also tightened the flatten function for the new allow-scripts config: nopt wraps single comma-separated strings in arrays for [String, Array] types, so each array entry needs splitting on commas before use. Refs: npm/rfcs#868

@JamieMagee

@JamieMagee

@JamieMagee

@Tayvon

npm's new opt-in install-script policy (npm/rfcs#868, shipping behind a preview in npm 11.16+, default from npm v12) blocks a dependency's preinstall/install/postinstall scripts unless it's listed in a top-level allowScripts field in package.json. esbuild (pulled in via tsx) and unrs-resolver (a transitive dependency, already in package-lock.json) both ship one; without this, a fresh `npm install` on a newer npm would block them with an advisory and require manual `npm approve-scripts`. Name-only entries (not version-pinned) so approval survives a patch/minor bump in the lockfile instead of silently lapsing. Sources: - npm/rfcs#868 - npm/cli#9360 (Phase 1 implementation) - https://docs.npmjs.com/cli/v11/commands/npm-approve-scripts Verified: package.json is valid JSON, `npm install` (this sandbox's npm 10.9.4, which predates the feature and simply ignores the unknown field) completes clean, tsc and lint both pass. Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Hp9rTAByfST7AkpQZfxpo5

@Tayvon

JamieMagee requested review from a team as code owners May 15, 2026 03:38

JamieMagee mentioned this pull request May 15, 2026

[RFC] Make install scripts opt-in npm/rfcs#868

Merged

JamieMagee force-pushed the jamiemagee/install-scripts-phase-1 branch 6 times, most recently from 3bb254c to e4270f0 Compare May 15, 2026 22:13

owlstronaut self-assigned this May 20, 2026

owlstronaut added the backport:v11 label May 20, 2026

saquibkhan added the FY26 label May 20, 2026