Not reliably. A model confirming its own suggestion is not independent evidence, because it has no live view of the registry unless a tool gives it one. The dependable check is to ask the registry itself: does this exact name exist, who publishes it, and when was it released.
What the research says about the problem
A study of package hallucination used 16 code generation models and two prompt datasets to produce 576,000 code samples in two languages. The authors report that the average share of hallucinated packages was at least 5.2% for commercial models and 21.7% for open source models, with 205,474 unique hallucinated package names. They also tested mitigation strategies and report that some significantly reduced hallucinations while keeping code quality. I read the abstract, not the full methods, so read the paper before relying on any specific mitigation.
The point for everyday work is simple. Non existent names are a normal, measured failure mode. You cannot assume a confident answer is a correct one. For more on what the numbers mean, see what the package hallucination study numbers mean.
Why self checking is weak
When you ask a model, are you sure this package exists, two things can happen. If the model has no registry access, it answers from the same memory that produced the name. A fabricated name can sound just as familiar the second time. If the model has a search or registry tool, the answer is only as good as that tool call, and you still cannot see what was queried unless you read the log.
A name that exists is also not a name that is safe. Existence is the weakest of the checks. A freshly registered lookalike exists too.
A ten second check that does work
For npm, the view command prints registry data for a package. The npm documentation shows it taking a package spec and optional fields, and that the default version is latest. A few useful commands:
npm view some-package name version
npm view some-package time
npm view some-package repository.url
If the name does not exist, you get an error, which is exactly the signal you wanted. If it exists, read the publish dates and the repository link. A package whose first release was days ago, with no real repository, deserves a pause even when the name looks right.
For Python, open the project page on the registry and read the release history and project links, since the assistant's name may be an import name rather than the install name (see why assistants get pip install names wrong).
Build the check into the workflow
- Never run an install line from a chat window without a lookup first. Make it muscle memory.
- Give the assistant a real tool if you can. A registry lookup or a dependency scanner exposed through an approved tool gives it facts instead of memory. Still read the output yourself.
- Gate it in the pull request. A reviewer or an automated check should flag any package that is new to the repository, with its first release date shown.
- Keep an allow list for common libraries. Names on the list need no lookup, everything else does.
Quick check
If the assistant says the package is popular, is that enough?
No. Popularity claims from a model are not data. Check download and release information from the registry, and compare the name letter by letter with the official documentation.
Does a clean install prove the name was right?
No. A successful install only proves a package with that name exists. It does not prove it is the project you meant.
Safeguard's SBOM and dependency scanning gives you a record of the components a repository actually contains, which helps close the gap between a suggestion and a verified component. You can also run the free scan at gold.safeguard.sh/scan against a repository after the fact.
Sources
- Spracklen et al., We Have a Package for You (arXiv 2406.10279): https://arxiv.org/abs/2406.10279
- npm Docs, npm view: https://docs.npmjs.com/cli/v10/commands/npm-view
Last reviewed: 19 October 2026.
