Don't stop here
Hand-picked guides our readers explore right after this one.
Stunning image generation with Midjourney prompt mastery
Read the guideMaster ChatGPT with advanced prompting techniques, mega-prompts, and proven frameworks
Read the guideAI prompts for content ideation, scriptwriting, repurposing, and audience growth strategies
Read the guideThe generated code imports a library with a perfectly sensible name, you run the install, and the registry says it does not exist. The obvious reaction is annoyance, but this specific failure deserves more care than an ordinary error, because attackers have industrialized it. The pattern is called slopsquatting: models repeatedly invent the same plausible package names, someone registers those exact names on npm or PyPI, and the next developer or autonomous agent that runs the suggested install command pulls attacker-controlled code straight into the build. Independent research across frontier models has measured package hallucination in a meaningful share of code-generation responses, and found sets of hallucinated names still sitting unregistered and available for anyone to claim. At least one hallucinated name has already been observed in the wild as a real malicious package with ongoing weekly downloads. So the correct response to 'package not found' after an AI suggestion is not to search harder for a way to install it. It is to verify what the real package is called, and never to install a name you cannot trace to a genuine project.
npm install or pip install fails with a not-found error for a plausible-sounding name
ModuleNotFoundError or 'Cannot find module' at runtime on an AI-suggested import
The package name looks right but no repository or documentation exists for it
The registry page exists but shows near-zero downloads and was published very recently
The suggested API does not match the real library's documentation
An agent retries the failing install repeatedly instead of stopping
Package names are highly predictable in shape, so a model can produce a name that reads exactly like a real one without any such project existing. Research across several frontier models has found package hallucination in roughly the low single-digit to six percent range of code-generation responses, which is small per response and very large in aggregate.
A frequent pattern is a name that merges two genuine tools, or that moves a plugin's name from one ecosystem convention to another. The result sounds authoritative because both halves are real, which is exactly what makes it convincing.
Real libraries move: to a scoped name, to a successor project, or out of maintenance entirely. Training data captures the old name, so the suggestion was correct at some point and simply is not any more.
A Python package name suggested for npm, or a Ruby gem name suggested for pip. The library genuinely exists, just not in the registry you are installing from.
This is the dangerous case. Attackers monitor which non-existent names models suggest repeatedly and register them. The install then succeeds, which is far worse than failing, because nothing signals that anything went wrong.
When to try: First, before anything else
A not-found error is the safe outcome. Never work around it by trying variations of the name until one installs, and never accept an agent's retry that suddenly succeeds. A name that failed yesterday and installs today is a specific red flag, not good luck.
When to try: Immediately after the install fails
Search npmjs.com or pypi.org directly for the functionality rather than the suggested name, and cross-check against the ecosystem's own documentation or awesome-list. Identify the canonical library by its repository and maintainer, then use that exact name.
When to try: Every time you install something you did not choose yourself
On the registry page check: a linked source repository that actually exists, a download count consistent with the project's reputation, a publish history going back further than a few weeks, and a maintainer with other work. A package with a recent first publish, no repository, and low downloads should not be installed regardless of how well the name matches.
When to try: Before searching the registry manually
Reply with: 'Confirm the exact registry name and link the source repository and documentation page. If you are not certain this package exists, say so.' This frequently surfaces the fabrication directly, and when the library is real you get the canonical name and docs in one step.
When to try: As a standing project setting
Commit your lockfile and install with npm ci or a pinned requirements file rather than resolving fresh each time. This prevents a name that resolves to nothing today from silently resolving to someone's newly registered package tomorrow, on a build machine, with no one watching.
When to try: Before giving any agent shell access
Do not allow autonomous coding agents to run package installs without approval. Agents are the highest-risk path here because they retry, they do not evaluate whether the resolved package is legitimate, and the install runs before any human sees the name. Put installs behind a confirmation step.
When to try: After any AI-assisted session that added dependencies
Go through your manifest and confirm every entry is a package you recognize or can trace to a real project with a repository and history. Run npm audit or pip-audit as well, though note that these catch known vulnerabilities and will not flag a brand new malicious package.
When to try: As soon as you suspect you installed a fake package
If you installed a name you now believe was hallucinated, assume the install ran arbitrary code. Remove it, delete node_modules or the virtualenv, reinstall from a clean lockfile, and rotate any credentials that were present in that environment or its CI. Install scripts execute with your permissions, so exposure is not limited to what your application imported.
Treat every AI-suggested dependency as unverified until you have opened its registry and repository pages
Commit lockfiles and install from them so names cannot silently start resolving later
Require human approval for any install command an agent wants to run
Prefer well-known libraries you can name yourself over whatever the model reaches for
If you believe you installed a malicious package, report it to the registry (npm and PyPI both have security reporting routes) so it can be removed for everyone, and notify your own security team if this touched a work machine or CI. If a public repository was involved, GitHub's security advisory process is the route for coordinating disclosure. There is no useful ticket to file with the AI vendor over a hallucinated name, since it is a known property of generation rather than a specific defect, but do report the resolved malicious package itself, which is actionable.
Package names follow highly regular patterns, so a model can generate one that reads exactly like a real library without any such project existing. Research across multiple frontier models has measured hallucinated package names in a few percent of code-generation responses, which is rare in any single answer and extremely common across an ecosystem's worth of usage.
The practice of registering package names that AI models repeatedly hallucinate, so that the next person who runs the suggested install command downloads attacker code. It differs from typosquatting in that the victim does not make a typo: they follow a confident recommendation. Researchers have found hallucinated names shared across several major models still unclaimed and available to register.
No, and a name that failed earlier and installs now is a specific warning sign. Check the registry page for a linked repository, a publish history longer than a few weeks, and download counts consistent with the project's reputation. A recently published package with no repository and few downloads should be removed, not trusted.
Search the registry for the functionality rather than the suggested name, and cross-check the ecosystem's official documentation. Hallucinated names often merge two real tools, so searching each half separately usually surfaces the genuine package. You can also ask the assistant to link the source repository, which tends to expose the fabrication straight away.
Considerably. An agent may run the install itself, retry on failure, and continue building on top of the result before any human reads the package name. Hallucinated install instructions have been observed propagating through agent-authored repository files, with agents attempting the install repeatedly. Require approval for installs.
Product behavior and limits can change. These primary sources were used to verify this guide.