About installaudit
installaudit is a CLI and MCP server for npm project maintainers who want to inspect install-time code before installing a dependency tree. It reads package.json and package-lock.json without installing packages or running scripts, then reports findings and a verdict.
Key features
- 01Inventories dependency install scripts
- 02Separates direct and transitive dependencies
- 03Classifies root lifecycle scripts
- 04Reports severity, counts, and verdict
- 05Deterministic JSON reports
Use cases
- 01Review install-time code before installing an npm project
- 02Inspect lifecycle scripts in a repository
- 03Get structured install-script findings through MCP
MCP support
Exposes the audit_install_scripts tool, which takes a path and returns the report as JSON, including verdict, counts, and findings.
Configuration
Local server config is the same for every client. Copy it into your client’s MCP config file.
Tools
1Saved tool list · updated 1d ago
| Parameter | Type | Required | Description |
|---|---|---|---|
| path | string | Yes | Target path to check |
Details
From the project READMEinstallaudit
Installing is running code. installaudit tells you whose code, before you install.
npm install does not just download files. Any package whose lockfile entry carries hasInstallScript: true runs code at install time, and so do the root package's own preinstall, install, postinstall, and prepare scripts. Most audits ask whether a dependency is vulnerable. installaudit asks a prior question: what executes the moment you install this tree?
It reads package.json and package-lock.json, inventories every install script in the tree, separates direct dependencies from transitive ones, classifies the root scripts by what they do, and returns a verdict. It never installs anything, never runs a script, and never fetches a package.
Install
npx @reneturcios/installaudit audit
Or install it globally, or add it as an MCP server (below).
CLI
# Audit the current directory
npx @reneturcios/installaudit audit
# Audit another path
npx @reneturcios/installaudit audit ~/src/my-repo
# Machine readable output
npx @reneturcios/installaudit audit ~/src/my-repo --json
# Run as an MCP server on stdio
npx @reneturcios/installaudit mcp
# Print the version
npx @reneturcios/installaudit --version
Exit codes:
0when the verdict is CLEAN.1when the verdict is REVIEW.2for usage errors, including a missingpackage.jsonor a missingpackage-lock.json.141when the reader closed the output pipe early.
MCP
Add to your MCP client config:
{
"mcpServers": {
"installaudit": {
"command": "npx",
"args": ["-y", "@reneturcios/installaudit", "mcp"]
}
}
}
Tool: audit_install_scripts, taking a path argument. It returns the full report as JSON: verdict, counts, and findings.
How the inventory works
Dependencies come from the lockfile, not from package.json alone, because the lockfile is the resolved tree that will actually be installed.
- Lockfile v2 and v3 format: the
packagesobject maps install paths such asnode_modules/<name>to entries. - An entry with
hasInstallScript: trueruns code at install time and becomes a finding. - The package name is taken from the segment after the last
node_modules/segment of the path. Scoped names take two segments:node_modules/@scope/nameis@scope/name, andnode_modules/a/node_modules/@scope/nameis also@scope/name. - A package is direct when its path has exactly one
node_modulessegment and its name is listed in the rootpackage.jsonunderdependenciesordevDependencies. Everything else is transitive, including a nested copy whose name happens to match a direct dependency. - The
versionand thedevflag are read from the lockfile entry and reported with the finding.
Root scripts come from package.json. Only preinstall, install, postinstall, and prepare are read, because those are the scripts npm runs around install. Each one present is a finding, classified from its command body.
Rules
| rule | severity | what it means |
|---|---|---|
DEP-INSTALL-SCRIPT | medium (direct), low (transitive) | A dependency whose lockfile entry has hasInstallScript: true. Evidence is name@version. |
ROOT-SCRIPT-NETWORK | high | A root lifecycle script classified as NETWORK. |
ROOT-SCRIPT-SHELL-OUT | medium | A root lifecycle script classified as SHELL-OUT. |
ROOT-SCRIPT-BUILD | low | A root lifecycle script classified as BUILD. |
ROOT-SCRIPT-OTHER | info | A root lifecycle script classified as OTHER. |
Root script classification uses simple, documented patterns, checked in this priority order: NETWORK first, then SHELL-OUT, then BUILD, then OTHER.
| class | patterns |
|---|---|
| NETWORK | curl or wget, or an http:// or https:// URL combined with a fetch or download tool word (fetch, download, curl, wget). |
| SHELL-OUT | A shell interpreter word (sh, bash, zsh), node -e, or a script interpreter word (python, python3, perl, ruby). |
| BUILD | tsc, npm run build (also pnpm, yarn, and bun), or a build tool name (webpack, vite, rollup, esbuild, parcel, gulp, grunt, babel). |
| OTHER | Anything else. |
Counts reported in every report:
totalDeps: every dependency entry found in the lockfilepackagesobject, excluding the root entry.depsWithScripts: entries withhasInstallScript: true.directWithScripts: the direct subset ofdepsWithScripts.transitiveWithScripts: the transitive subset ofdepsWithScripts.rootScripts: root lifecycle scripts present amongpreinstall,install,postinstall, andprepare.findings: total findings.
Findings are sorted deterministically by rule, then by name. Reports contain no timestamps, so the same tree always produces the same report.
Verdict
CLEAN: no root NETWORK or SHELL-OUT scripts, and no dependency install scripts. A root BUILD or OTHER script alone still verdicts CLEAN; it is reported as a low or info finding, not hidden.REVIEW: anything else. At least one thing in this tree runs code at install time that is worth a human look.
Limits
- Lockfile-based only. A missing
package-lock.jsonis an error (exit 2), not an empty report, because without the lockfile there is no resolved tree to inventory. A missingpackage.jsonis likewise an error. - Script bodies of dependencies are not in the lockfile and are not fetched. For a dependency, installaudit reports presence, name, version, dev flag, and direct or transitive position. It does not report what the script does and does not judge intent. A package with an install script may be entirely legitimate; native builds are the common case.
- Root script classification is pattern based. It reads the literal command text in
package.json; it does not follow a script into the files it invokes, expand variables, or trace what a downloaded file would do. - Only lockfile v2 and v3 are supported, through the
packagesobject. The legacy lockfile v1dependenciesobject is not read, so a v1 lockfile is an error rather than a half inventory. - Only the four install-adjacent root scripts are read. Other scripts, such as
testorstart, are out of scope even when their commands look risky. - Direct means listed in
dependenciesordevDependenciesof the rootpackage.json. A dependency that is only reachable through the tree is transitive by definition here, regardless of who maintains it.
Comments
New to MCP?
From what the protocol is to installing your first server, these answers cover most first questions.
An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.