You asked your coding agent to add a feature, and it answers with one line: just install this package. You paste the command, the install finishes, and you move on. That single line is the moment your project decides to trust a stranger, and it takes about two minutes to check.
The short version: before you run any install command an agent hands you, open the registry and confirm the package is real, that someone real publishes it, and that the linked repo is the one you expect. One browser tab, one terminal line. Everything below is that check, written out.
Why "just install X" is a trust decision, not a typo
Your agent does not know a package exists. It predicts text that looks like a working install command, and sometimes that prediction names a package that was never published. Researchers measured this: across 576,000 generated code samples, the average share of hallucinated packages was at least 5.2% for commercial models and 21.7% for open-source models (the paper). The authors call it a new form of package confusion attack.
A missing package is not just an error you hit and fix. Anyone can publish a package under a name a model tends to invent, and then the install succeeds because someone made sure it would. A wrong name and a malicious name look identical in your terminal. That is the whole reason this is a trust decision you make, not a typo you fix afterward.
The two-minute check
Run this before any npm install or pip install an agent proposes.
For Node, ask the registry what it holds:
npm view <package-name>
A 404 / "is not in this registry" error means the package does not exist, so stop. If it prints, read who publishes it, when the first version landed, and the linked repository.
For Python, open https://pypi.org/project/<package-name>/. The page shows the maintainer, the release history, and the source link.
Then work through five questions.
- Does it exist on the registry at all. A "not found" is your answer, so do not install.
- Who publishes it. A long history under one name is a good sign. A first release from last week is not.
- When was it first published. A package you are told is "standard" that appeared days ago deserves a pause.
- How many people use it. Weekly downloads are a rough signal, not proof, but a popular-sounding name with almost no downloads is a red flag.
- Does the linked repo match. Open the repository the registry points to and check the name, maintainer, and description line up with what the package claims to be.
One more, for Node, before anything runs. A package can execute code at install time, so check for scripts:
npm view <package-name> scripts
An unexpected postinstall or preinstall step deserves a read. Prefer packages that do nothing until you import them.
If you want an agent to take some of this legwork, you can try the zcode agent harness free, though you should still read its output against the registry yourself (the zcode and GLM links in this post are our referral links).
Lockfiles and exact installs
The second half of the problem is what happens after the first install. A lockfile records the exact versions your project uses, so a teammate or a build server gets what you got.
In Node, commit package-lock.json and install from it with npm ci, which installs exactly what the lockfile pins instead of resolving fresh versions.
In Python, pin your dependencies and verify them. The pip docs on secure installs cover installing from a requirements file with hashes, so a downloaded package has to match the expected fingerprint.
The point: locked versions with checked hashes cannot quietly pull in something new when a change merges. An install that only ever says "latest" can.
If you are picking a paid plan for the agent doing this work, our referral link gets you 10% off GLM coding plans.
npm audit and pip-audit are a baseline, not a shield
Run npm audit or pip-audit and fix what they flag. They match your installed versions against known advisories, and that catches real problems.
They only know about problems someone already reported, though. A package published this morning, built to lift your environment variables, has no advisory yet, because nobody has filed one. The audit would pass it. That gap is exactly what the check above closes.
A rule for your project instructions file
Most agents read a project instructions file at the start of a session. Add one line so a silent install becomes a question you get to answer:
Never add a dependency without asking. Propose it with the registry link and one sentence on why it is needed.
That keeps you the person who decides what enters your project, which is where the decision belongs.
The copy-paste checklist
Save this and run it every time an agent proposes a new package.
New package checklist
[ ] Name exists on the registry
Node: npm view <name>
Python: pypi.org/project/<name>/
[ ] Publisher and first-publish date look sane
[ ] Weekly downloads match the maturity claim
[ ] Linked repo matches the name and maintainer
[ ] No unexpected install scripts
Node: npm view <name> scripts
[ ] Lockfile committed, install with npm ci
(or hashed pip install)
[ ] Audit run: npm audit / pip-audit
[ ] Project instructions line added:
"Never add a dependency without asking.
Propose it with the registry link."
For the wider version of this, our post on how to secure your vibe-coded app before you ship runs the same trust questions across secrets, permissions, and inputs. There is more on our blog if you want to keep going.
If this saved you from a bad install, a tip on the post goes a long way. Thanks for reading.
Latest comments
0