Not always, but treat them as a distinct risk class that needs explicit approval. An install script runs code on the machine doing the install, so it should never be allowed by default in CI. Disable scripts globally, then allow them for a short, reviewed list of packages that truly need them.
What an install script is
Some packages declare commands that run automatically around installation, for example to compile native code or download a binary. The npm configuration reference describes the ignore-scripts option: when set to true, npm does not run scripts specified in package.json files. It also notes that commands explicitly meant to run a script, such as npm start or npm test, still run their intended script, though without pre or post scripts.
The default for that option is false, which means scripts run unless you change it.
Why intake should care
A library that only contains code does nothing until your application imports it. An install script runs at install time, on a developer laptop or a build runner, with that user's permissions and often with network access. That is a different level of trust, and it is a common route for malicious packages.
Three policy options
| Option | How it works | Trade-off |
|---|---|---|
| Allow by default | Scripts run everywhere | Fastest, widest exposure |
| Block by default, allow by list | Scripts off in CI and on laptops, allowlisted packages run through a controlled step | Good balance for most teams |
| Block entirely | No scripts, ever | Some native packages will not work |
The middle option is the one most teams can live with.
How to run the middle option
- Turn scripts off in shared config. Set the ignore-scripts option in the project or shared config file so that every install skips them.
- Find what breaks. Run the build and list the packages that needed their scripts.
- Review each one. Why does it need the script, what does it download, and from where?
- Run the approved ones explicitly. Use a separate, logged build step that rebuilds only the named packages.
- Alert on new scripts. In intake, flag any new version that adds or changes an install script compared with the last approved one.
What to review in a script
- Does it download anything, and is the source pinned and verified with a checksum?
- Does it read environment variables or files outside the package directory?
- Does it make network requests unrelated to its purpose?
- Is the script short enough to read in minutes?
If you cannot explain why a script needs network access, that is your answer.
Limits of this control
Ignoring scripts reduces exposure at install time. It does not stop malicious code that runs when the package is imported, so it is one layer, not a complete defence. Combine it with source controls, scanning and a cooling-off period.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a package entry and note what metadata is available, which is the starting point for deciding whether it needs a closer look.
Where Safeguard fits
Safeguard's dependency scanning and policies can help you flag packages that need review before they merge. The free scan is a way to see your own inventory.
Quick check
Will turning off scripts break my builds?
Possibly for packages that compile native code. Test in a branch and build an allowlist of those that need their scripts.
Is ignoring scripts enough to be safe?
No. Code can still run when the package is loaded, so keep scanning and review in place.
Sources
Last reviewed: 19 October 2026.
