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.
Short version
Treat package installs and one-line runners as potential code execution. npm and pnpm run lifecycle hooks; Bun blocks arbitrary dependency hooks by default unless you mark packages as trusted; Composer has script events; pip needs hash/lock discipline because the risk is still untrusted code on a real machine. Especially at home, where email, browser sessions and family files sit nearby.
If you only do one thing, start here
Best: spare device or VM with no real accounts. Good: dev container or separate OS user with no saved sessions/tokens. Limited: separate browser profile for web separation only, not for containing software you run.
Done when
You can answer this without guessing: Can this install run lifecycle scripts?
If you have five more minutes
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.
Read one step at a time, then ask where the command runs and which secrets sit nearby.
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.
Teaching model, not a scan: these toggles do not inspect your home. Treat amber or red results as prompts for a real check on the device, account, router or family process they describe.
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, separate OS user or spare device rather than your main daily-use account. A browser profile is not containment for code execution.
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.
Self-check questions
Use these quick checks to find the next practical fix. The useful answer is not perfect security; it is whether the safer path is obvious when someone is tired, embarrassed or in a hurry.
Before running npm, pnpm, bun, pip, Composer, curl|bash, npx or bunx, what can this command reach from this shell?
Good sign: The command runs in a container, VM, separate OS user or spare device with no saved browser sessions or sensitive tokens.
Watch for: A fast demo install on the daily laptop can see far more than the project folder if scripts run.
Are SSH keys, cloud tokens, package tokens, .npmrc/registry tokens, cloud CLI credentials, GitHub tokens, synced folders, password-manager access or work credentials available in this terminal or browser profile?
Good sign: Secrets are outside the test environment, and the project cannot casually read home directories, agents or synced folders.
Watch for: Home dev machines often have the exact mix malware likes: email open, cloud synced, keys loaded and curiosity high.
What changed in package scripts, lockfiles or installer instructions since the last trusted run?
Good sign: Lifecycle hooks and new dependencies are checked before install; serious projects use frozen lockfiles.
Watch for: Postinstall output that flashes by quickly is still code execution, not harmless setup theatre.
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.
Why this advice holds
Know what can run during package installs, why lifecycle hooks matter, and how to keep hobby code away from sensitive accounts.
JavaScript package managers such as npm and pnpm support lifecycle hooks including preinstall, install and postinstall. Bun takes a safer default by blocking arbitrary dependency lifecycle scripts unless a package is trusted, which is exactly why the setting matters. Composer has script events too. The common household lesson is simple: an installer can cross the line from fetching files into running code.
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: VM, dev container, separate OS user or throwaway test machine. A browser profile can help separate web sessions; it does not safely contain software executed on the computer. For serious projects, use lockfiles, frozen installs, registry controls and deliberate review of dependency/script changes.
Disabling lifecycle scripts can help review what a project wants to run. It is not a permanent safety guarantee. If enabling scripts is required, inspect the commands and dependencies before doing it.
Look beyond the project folder: environment variables, shell startup files, SSH agent, .npmrc, registry tokens, cloud CLI credentials, GitHub tokens, browser sessions and synced folders can all be in reach.