I Let Claude Code Install Packages for a Week — Here's How Many Didn't Exist (The Slopsquatting Trap)

Slopsquatting is a supply-chain attack that turns an AI model's mistakes into a delivery mechanism for malware. It works in four steps. First, a developer asks an AI tool for code, and the generated code references a package that does not exist — a hallucination. Second, an attacker notices that models keep inventing the same plausible-sounding name. Third, the attacker registers that exact name on a public registry like npm or PyPI and fills it with malicious code. Fourth, the next time anyone's AI suggests that name and they run the install, the malware lands on their machine and in their build.

The name is a blend of 'slop' — the community's term for low-quality AI output — and 'typosquatting', the older trick of registering misspelled versions of popular packages. The difference is the bait. Typosquatting bets on a human typo. Slopsquatting bets on a machine hallucination, which is both more predictable and more trusted, because the developer assumes their AI knows what it is talking about.

That trust is the actual vulnerability. The malware does not break through a firewall. It walks in through your assistant's confidence.

I wanted a result I could trust, not a vibe. So the method was deliberately boring and fully reproducible — you can run the exact same thing.

For seven consecutive working days I did my normal job: feature work on the ERP, two client repos, and some StackNova tooling, with Claude Code as the primary driver. The only change was instrumentation. Every time Claude Code proposed or ran an install command — npm install, pnpm add, pip install — I captured the package name, the ecosystem, the date, and whether it was a direct dependency I asked for or a transitive one it pulled in.

At the end of the week I ran every captured name against the live registry to answer one question per package: did this exist at the moment the AI suggested it? The manual check is fast — npm view for npm, pip index versions for PyPI — and I cross-checked anything suspicious on npmjs.com and pypi.org directly, noting download counts and creation dates. To make this repeatable for anyone, I also ran the full list through slopcheck, an open-source CLI that checks names across npm, PyPI, crates.io, Go, RubyGems, Maven and Packagist in one pass and outputs JSON.

If you want to reproduce it, the core of the experiment is two habits: log every install for a week, then batch-verify the names. Everything in the results section below comes from that log.

Across the week, Claude Code touched [[FILL: total install commands Claude Code ran or suggested]] install commands covering [[FILL: total unique package names]] unique package names, spread over [[FILL: number of real client/ERP work-sessions over the week]] real work sessions.

Of those names, [[FILL: how many did not exist on the registry at suggestion time]] did not exist on the registry at the moment they were suggested — a hallucination rate of [[FILL: your hallucination rate as a percentage]]. [[FILL: how many appeared as transitive/nested deps vs direct]] of the issues showed up not as something I asked for directly but buried as a transitive dependency, which is the more dangerous case because those never appear in your package.json for you to eyeball. I also saw [[FILL: how many were cross-ecosystem confusions, e.g. an npm name suggested for a pip install]] cross-ecosystem confusion, where a name that only exists in one registry was suggested for another — a known failure mode where a model recommends an npm-only name for a pip install.

The single example that stuck with me: [[FILL: one concrete example of a hallucinated name Claude Code gave you]].

Honest interpretation: this is roughly what the research predicts for a frontier model. The widely-cited 19.7% figure is dominated by small open-source models; commercial frontier models in the same study landed near 5%, and Claude Code is built on exactly that class of model. So a low number here is not Claude Code getting lucky — it is the expected behavior of a strong model. The point of the experiment is not the headline rate. It is that the rate is not zero, the transitive cases are invisible by default, and a single bad install only has to happen once.

To understand why slopsquatting works, you have to understand that the hallucinations are not random noise. That is the whole danger.

A language model does not 'know' which packages exist. It predicts the most statistically likely sequence of tokens given your prompt. For a common, well-documented library, the likely tokens spell a real package name. For a more unusual request, the model can confidently assemble a name that fits every pattern of a real package — sensible words, a plausible scope, the right shape — except it was never published. The model is not lying; it has no concept of a registry to check against.

The comprehensive evidence here is the 2025 USENIX Security paper 'We Have a Package for You!', which tested 16 models and generated 576,000 code samples. It found that 19.7% of all package references were hallucinated, totaling 205,474 unique non-existent names. The split was stark: about 5.2% for commercial models versus 21.7% for open-source ones. But the finding that makes slopsquatting viable is repetition. When the researchers re-ran the same prompts ten times, a majority of hallucinated names showed up again, and a large share appeared in all ten runs. A mistake that repeats is a mistake an attacker can predict — and pre-register.

That is the bridge from 'AI makes errors' to 'AI errors are an attack surface.' The unpredictability of a hallucination would make it useless to attackers. Its predictability is what turns it into a target list.

Slopsquatting is not a thought experiment. Two cases prove the chain end to end.

The first is the one that named the category. In 2023, security researcher Bar Lanyado noticed that models kept recommending a Python package called huggingface-cli — a name that sounds exactly right but is not how that tool is actually installed. To test the risk, he registered an empty, harmless package under that hallucinated name on PyPI. In three months it pulled more than 30,000 genuine downloads, and the fake install command even ended up pasted into the public README of a repository belonging to a major tech company. The package was harmless because Lanyado made it harmless. An attacker would not have.

The second is more recent and more pointed at how we work now. In January 2026, a hallucinated npm package called react-codeshift spread through hundreds of repositories — not because anyone deliberately planted it, but because AI-generated agent instruction files kept referencing the non-existent name, and tooling kept trying to fetch it. That is slopsquatting colliding with the agentic era: the fake name propagating through the very config files that agents read and act on.

Neither incident was a catastrophe, but only by luck and good-faith researchers. They are the controlled demonstrations that tell you the live version is a matter of when, not whether.

Here is the reframe that changed how I work. The problem is not that Claude Code occasionally suggests a name that does not exist. A strong model does that rarely, and when I am reviewing, I catch it. The problem is the mode where I am not reviewing.

When you run an agent in an auto-accept or bypass mode — letting it execute installs without stopping for approval — you have removed the one human checkpoint that would have caught a fake package. The agent will proceed if it has the authority, because that is what you told it to do. Combine that with vibe coding, where you describe an outcome and never manually type or read the dependency names, and you can ship a package you never consciously chose, never verified, and never even saw.

The cleanest mental model I have found comes from security guidance around CI-connected agents: an automated AI workflow should not simultaneously hold all three of these powers — reading untrusted input, having access to secrets or your real environment, and being able to act externally such as installing or running code. Keep any one of those out of the loop and a single bad suggestion cannot become a breach. For day-to-day coding, the easy version is: never give an agent unattended install authority over an environment that also holds your credentials.

None of this requires a paid scanner or a big process change. It is a handful of settings and one new habit. I run all of these now.

First, keep installs reviewable. In Claude Code (or Cursor), do not run a blanket auto-accept for shell commands in a repo that has access to real secrets. Let it propose the install; glance at the name; approve it. That single beat of attention is the cheapest defense in existence.

Second, turn on a release-age cooldown. This refuses any package version published less than N days ago. Because most malicious packages are caught and pulled within 24 to 48 hours, a 7-day cooldown means your machine simply never sees the dangerous window. This is the highest-impact, lowest-effort control available and it is now supported across every major package manager (see the table).

Third, commit your lockfile and install from it. Use npm ci (or the pnpm/yarn equivalent) in CI so builds resolve to the exact, already-vetted versions rather than re-resolving to whatever is newest. Add --ignore-scripts where practical so a malicious package cannot execute install-time code, and allowlist the few legitimate packages that genuinely need build scripts.

Fourth, verify names automatically. Put a check in CI that fails the build if a dependency name does not exist on its registry or looks freshly minted. The open-source slopcheck action does this across ecosystems; Socket and Datadog's Supply-Chain Firewall wrap the install command itself and block known-bad packages before they land. Tools like Aikido Safe Chain intercept npm, pnpm and yarn installs and add their own cooldown.

Fifth, watch for cross-ecosystem names. If an AI suggests pip install for a name you only recognize from npm (or vice versa), stop. That mismatch is a classic hallucination signature.

When an AI tool tells me to install something I do not recognize, I run through this in about fifteen seconds before approving. It is short on purpose, because a defense you skip protects nothing.