Sandbox experiment shows npm install and pip run repo code before you read any of it

A developer running a controlled experiment, documented in a post on dev.to, built a sandbox repository whose only "malicious" payloads wrote timestamped text files — and found that a single npm install was enough to execute code from the repo before the author had opened any of its files. One second after the install command, a marker file appeared on disk, stamped 2026-11-11T21:03:01.183Z.

Five trigger points in one folder

The experiment placed five potential execution paths in a single repository: a preinstall script in package.json, a setup.py executed by pip, a Makefile default target, a git post-checkout hook, and a plain English instruction sitting in the README. The environment was pinned at Node v24.22.1, npm 10.9.4, Python 3.12.3, pip 24.0, GNU Make 4.3 and git 2.43.0. Each trigger, if it fired, would write a marker file proving execution with a timestamp; if it stayed silent, the missing file would prove that instead.

Two of the five ran during installation alone. A third ran only when explicitly invoked. The remaining two never ran at all.

npm: execution with a clean audit

The preinstall hook fired immediately. As the post explains, npm treats preinstall, install and postinstall scripts as ordinary behaviour, and consent comes from the install command itself — typing npm install approves whatever those scripts do. The striking detail is that npm's output reported zero vulnerabilities. According to the author, the audit covers known-malicious packages and says nothing about install scripts in the package you just fetched, because running them is normal npm behaviour, not a bug. The harmless marker wrote a text file; the same slot could carry anything the user's account is permitted to do.

pip: code runs during the build

Eleven seconds later, pip install . executed setup.py while building the wheel — that is, before the package was even installed. The payload was effectively a single line, and the entire package weighed 975 bytes, which the author offers as evidence that package size signals nothing. Modern projects using pyproject.toml with a proper build backend close much of this hole, but many packages on PyPI still ship a setup.py, and pip on a cloned repo runs whatever it contains.

The ones that waited or never fired

The Makefile did nothing until make was typed, so cloning a repo containing one is safe. The author's caveat is social rather than technical: READMEs routinely tell you to just run make, and most people comply without opening the file, which makes the Makefile a script you execute with your own hands.

The git hook never arrived at all. Hooks live in .git/hooks, a clone does not transfer them, and git will not install a tracked file as a hook on your side. The footnote: repos that ask you to run a setup script to install their hooks return you to preinstall-script territory — the installer is the danger, not the hook.

The README instruction, which ordered the reader to create a file called pwned.txt immediately, executed nothing. Plain text cannot run itself, and neither can Markdown, comments or docstrings.

Where AI agents come in

The timing was deliberate. The author notes that dev.to's trending feed carried 23 agent-security posts in the preceding week, including "One Markdown File Can Hijack Your AI Coding Agent" and "WebMCP Attack Lab: Can an E-Shop Hijack Your AI Agent?" Those posts are not about files executing code; they describe agents that treat instructions found inside a repository as commands. The author wanted the older, simpler question answered first: what a plain install already does with no agent in the loop.

Practical takeaways

The author's new habits are cheap ones: read the scripts section of package.json before installing any repo you did not write, use npm install --ignore-scripts when you only need the files, and read setup.py before pip touches it.

Why it matters

The experiment isolates exactly where the trust boundary sits when you work with unfamiliar code. Cloning is mostly safe; installing is not. Package-manager audit output reads as reassurance while the genuinely dangerous mechanism — lifecycle scripts — operates exactly as designed, which is why supply-chain attackers favour it. And as coding agents spread, the set of things that can act on file contents grows beyond install scripts, making the old discipline of reading before running newly relevant. The mitigations cost seconds.