Supply chain
Developers and tinkerers often run package installs at home on machines that also touch email, banking, family photos or work. Package managers can execute code during install. That tiny convenience gap is large enough to drive malware through.
Nigel version
Treat npm, pnpm, bun, pip, composer and one-line install scripts as code execution, not content download. Especially on a home machine with real accounts logged in.
Install path
This is why the page is blunt about package installs. The risky part is not reading a README. It is running setup inside the same user profile that holds real accounts.
Looks useful. Copy the setup command.
npm, pnpm, bun, pip or Composer resolves dependencies.
preinstall, install or postinstall can run before you inspect much.
Shell tokens, SSH keys, browser sessions and files become the prize.
The project lives away from useful secrets, so a bad install has less to steal.
A fast command from a README can still run code faster than a human can read the dependency tree.
Explain the jargon
Tap a term for the plain-English version and the practical move. No fake mystique, just the bit that changes what you do at home.
A package-manager hook that can run during install, such as preinstall, install or postinstall.
Do this: Check package.json and dependency changes before installing unfamiliar projects.
Convenience commands that fetch and run a package quickly. That speed is the point, and also the risk.
Do this: Run unknown tools in a container, VM or throwaway profile rather than your main daily-use account.
The set of accounts, files, tokens and sessions a mistake can reach from where you ran the command.
Do this: Keep browser sessions, SSH keys, cloud tokens and work material out of untrusted dev environments.
Full guidance
A practical supply-chain risk model for home developers: what runs, why postinstall scripts matter, and how to keep hobby code away from sensitive accounts.
JavaScript package managers support lifecycle hooks such as preinstall, install and postinstall. They are useful for legitimate build steps. They are also a direct path for a malicious package to run code during install, before the developer has opened the project.
Home development machines are messy by design: personal email open, browser sessions saved, cloud drives synced, SSH keys loaded, family documents nearby. That makes a malicious package install more than a developer inconvenience; it can become account theft or work-adjacent exposure.
Use isolation first: dev container, VM, separate OS user, throwaway test machine or at least a separate browser/profile. For serious projects, use lockfiles, frozen installs, registry controls and deliberate review of dependency/script changes. For quick experiments, assume the blast radius is the whole user profile unless you isolate it.
Scenario
A developer clones a promising weekend AI tool and runs npm install on the same laptop used for work email, banking and cloud storage.
Better response
Worse habit
Treating postinstall output as harmless setup noise because the demo looked useful.