The package your AI assistant invented, and someone registered

You ask an AI coding assistant how to do something, and it answers with the calm authority these tools always have: “Install the react-codeshift package and call it like this.” You copy the command it gave you, run npm install react-codeshift, and it installs without a murmur. The assistant was confident, the command worked, and you move on.

The catch is that the assistant may have invented that package. Large language models don’t look things up; they predict plausible text, and a plausible-sounding package name is exactly the kind of thing they’ll produce whether or not it exists. Most of the time an invented name simply fails to install and you shrug. But attackers have noticed that these tools hallucinate the same names over and over — and they’ve started registering those names for real, filling them with malware. So “just run the command it gave you” can now pull a stranger’s code straight into your project, and it installs as cleanly as the real thing would have.

That’s the quiet failure: not a broken command, but a successful one — a dependency that installs without complaint because someone was waiting for you to trust a name your assistant made up.

Why it stays invisible

Nothing about it looks wrong. A malicious package installs exactly like a legitimate one — same command, same green output, same “added 1 package”. There’s no warning, because from the tool’s point of view you asked for a package and it fetched one. The damage happens quietly during or after install: many attacks run code the moment the package is added, or wait until you use it, harvesting environment variables, tokens and keys and sending them off before anyone notices anything amiss.

The reason it’s more than a curiosity is that the hallucinations are predictable. Ask enough people’s assistants how to do a common task and a handful of invented names come up again and again — which turns a random slip into a targetable list. An attacker registers the popular ghost names once, and simply waits for the stream of developers who paste an install command without checking. Researchers have named this “slopsquatting”: squatting on the packages the “slop” invents. It rides on ordinary trust — the assistant sounded sure, the command ran, and verifying a dependency’s existence is the step nobody was taught to take.

The name in the opening isn’t made up for this piece, either. In January 2026 a researcher at the security firm Aikido found that react-codeshift — a package that had never existed, invented by a model mashing together two real tools — was being recommended in AI-generated agent instruction files across more than 230 repositories, with assistants still trying to install it daily. He registered the name himself before anyone less friendly could. The next ghost name won’t necessarily be claimed by the good guys first.

Find it yourself

Whether or not you write code yourself, you can check the habit that causes this — and check a suspect dependency — in about ten minutes.

1. Look up any package before you install it. Before running an install command an assistant gave you, open the package’s page on its registry directly: npmjs.com for JavaScript, pypi.org for Python. A real, trustworthy package has history: a maintainer, a repository link, versions going back over time, and meaningful weekly download numbers. A ghost that was registered last week to catch people out has none of that — brand-new, one version, no real history. If you can’t find the page at all, the name was invented; don’t install it.

2. Watch for the tell-tale signs of a trap. Be wary of a package that is very new, has almost no downloads, has a name suspiciously close to a well-known one (a letter off, or a hyphen added), or whose description and code don’t match what it claims to do. Any of these on a package your assistant suggested is a reason to stop and check with a person who knows the ecosystem.

3. Check what your project already pulled in. For an existing project, the dependency list is in a plain file — package.json (and package-lock.json) for JavaScript, requirements.txt or pyproject.toml for Python. Skim it for anything nobody recognises, then look each unfamiliar one up as in step 1. This catches ghosts that got in during earlier “just run the command” moments.

4. No command line needed for the check itself. Steps 1 and 2 are done entirely in a web browser on the registry’s own site. You don’t have to be the developer to sanity-check a name before someone installs it — reading a package’s history is something anyone can do.

The usual jolt is at step 1: a package that installed perfectly last month turns out to have been registered only days before you added it.

The fix

Good here isn’t distrust of AI tools — it’s a small habit of verification, plus a couple of defaults that catch the mistake if the habit slips.

Verify before you install, every time. Make “look it up on the registry first” the reflex whenever an assistant hands you an install command. It costs a minute and it’s the single step that defeats this entire class of attack, because the whole trick depends on you not checking whether the name is real.

Pin and lock your dependencies. Commit your lockfile (package-lock.json, poetry.lock, or a pinned requirements.txt) so your project installs the exact, reviewed versions every time rather than resolving fresh names on each machine. This stops a ghost slipping in unnoticed on someone else’s setup.

Let the tools help. Turn on the dependency scanning your platform already offers — GitHub’s Dependabot, npm audit, or pip-audit — so known-bad packages get flagged automatically. Treat these as a backstop, not a replacement for the look-it-up habit, since a brand-new malicious package won’t be on any list yet.

Give the same rule to your AI tools. If you use an AI agent that installs packages for you, tell it explicitly to verify each package exists on the official registry, with real history, before installing — and don’t let it run install commands unattended. The convenience of “it just did it for me” is exactly where this bites.

None of this needs a security team or a change of tools. It needs the small, calming discipline of treating a suggested package name as a claim to be checked rather than a fact to be trusted — a browser tab and a minute, before the command runs.

The habit underneath this one — treating a confident suggestion as something to verify rather than obey — is the same instinct that keeps the other quiet failures in this series from catching you out.