Sandboxing npm install: A new tool puts a denominator under 'npm install runs arbitrary code'

The npm ecosystem has a dirty secret: npm install runs arbitrary code. Every package can declare preinstall, install, and postinstall scripts, and those scripts execute with your user's privileges, network access, and full filesystem. For developers, this is a constant source of anxiety — but how much anxiety is actually warranted? A new tool, @kenwea/mcp, aims to put a number on it.

The tool, built by a developer who goes by kenwea, fetches the exact tarball npm install would grab, then executes the declared install scripts inside a tightly constrained sandbox: no network access, no capabilities, and a read-only filesystem. It returns a verdict — a signed statement binding the sha256 of the package bytes to what the scripts did under those constraints. The signature is generated by a published Ed25519 key, so you can verify the verdict yourself. No account is required; the service mints an anonymous rate-limit key on first call, with 20 checks per hour.

Why this matters

The motivation is admirably concrete. The author ran the tool across 658 MCP-related packages and found that 20 declared an install script (3.0%). But the real insight came from actually running those 20 scripts. Four used preinstall: npx only-allow pnpm — a pattern often dismissed as a benign guard to enforce a package manager. Yet all four made network calls at install time, because npx fetches only-allow from the registry. As the author puts it: "A manifest tells you what a script is; only running it tells you what it needs."

That's the core value proposition: moving from static analysis (what a package declares) to behavioral observation (what it actually does). It's a bit like running a binary in a VM to observe its syscalls instead of just reading its strings.

Honest scope

The author is refreshingly candid about the tool's limitations. Dependencies are not installed, so the verdict only covers the package's own declared install surface, not its transitive closure. And install-time is just one potential attack vector — a package can act at first import or at runtime. The verdict is a bounded, signed observation, not a safety oracle.

That honesty makes the tool more useful, not less. In a world of hype around AI and 'zero-trust' everything, a tool that says 'under these constraints, these bytes did X' is a breath of fresh air. It's a building block, not a silver bullet.

A call to the community

The author closes with an explicit invitation: "Tell me where it is wrong. The failure I most want is a package it clears that you would have flagged." This is the right spirit — adversarial testing is how security tools get better. The registry is full of edge cases: scripts that check for a TTY, refuse to run without a specific environment variable, or even detect the sandbox itself.

For developers, the tool's immediate appeal is risk assessment before running npm install on a suspicious package. The signed verdict adds a layer of accountability — you can check whether a package's behavior matches its hype. For the broader ecosystem, it's a stepping stone toward more rigorous supply-chain security tooling.

In a beat where 'left-pad' style incidents loom large, any tool that makes the hidden behaviour of npm install more visible is welcome. It's not a complete solution, but it's a solid addition to the developer's security toolkit.