Yes, they run automatically, with full filesystem and network access. And this matters more than it sounds: in a supply-chain attack, the postinstall usually IS the entire attack. It reads your environment variables, cloud credentials, .npmrc tokens and SSH keys and uploads them to an attacker server. The package's runtime code is often perfectly clean. So even with a cooldown and exact pins, one poisoned package added before your other defenses landed gets code execution at install time.
Block postinstalls by default and maintain a narrow allowlist of packages whose script is functionally required, typically just the few that compile a native module or download a prebuilt binary. pnpm 10+ blocks all postinstalls by default and requires an explicit allowlist, which is the safest default available today:
{ "pnpm": { "onlyBuiltDependencies": ["esbuild"] } }On npm the equivalent is the heavier hammer npm install --ignore-scripts, then npm rebuild <pkg> for the ones you actually need.
The decision rule for the allowlist: read the postinstall script first. If it touches the filesystem to install a real artifact (native compiler, binary fetcher), allow it. If it just prints a banner or pings home (donation messages, telemetry, "thank you for installing"), block it. And the bar that people get wrong: vendor reputation is not a free pass. A known vendor's postinstall can still be a banner the package works perfectly well without. The test is "is this postinstall functionally required", not "do I trust this vendor".
Layered defense: https://www.tigzig.com/agents-faq/how-to-protect-against-a-supply-chain-attack. Full item with code: https://www.tigzig.com/security/supply.
← All Agents FAQ