Package Hallucination in Coding Agents
Does the package an agent recommends exist, and is it the intended software?
Reference notes by Min · Reviewed October 15, 2026
Definition
Package hallucination occurs when generated code refers to a nonexistent or unintended software package. A coding agent that automatically installs such suggestions can introduce supply-chain risk, especially when package names later resolve to software controlled by an unrelated party.
A plausible package name can look like a normal implementation detail. The risk increases when the agent can immediately turn a suggestion into installed code. Treat new dependency adoption as an external software decision rather than a text-completion detail.
What it covers
- Suggestion
- The dependency name and claimed purpose.
- Resolution
- Which registry and package it actually identifies.
- Execution
- Installation and build-time behavior.
- Review
- Evidence supporting adoption of the dependency.
Distinguish hallucination from other supply-chain problems such as typosquatting or dependency confusion. They can lead to similar outcomes but have different causes. Verification should establish the intended project, source and artifact, not merely a successful registry lookup.
In practice
Practical design patterns by Min.
- Verify identity and provenance before installing a new dependency.
- Use approved registries and reviewed lockfiles.
- Keep exploratory installation away from production secrets.
Record why a dependency is needed and which version is approved. Use lockfiles and restricted installation routes where suitable. Inspect install-time execution and transitive dependencies, and ensure the agent cannot silently change the registry to make a failed suggestion resolve.
Research notes
Source-grounded details and editorial applications. Follow each link for the original document.
Generated dependencies need verification
We Have a Package for You! empirically examines package hallucinations in code-generating models. The study supports treating dependency suggestions as unverified, while its reported rates are specific to its experimental setup.
Source: We Have a Package for You! Package Hallucinations by Code Generating LLMs ↗
Working example
An agent proposes a convenient PDF library
The generated code imports a package the team has never used.
- Confirm the intended package through authoritative documentation.
- Review the resolved artifact and dependency change.
- Evaluate it in a constrained environment before including it in the release.
Why the controls matter
The PDF example should be validated against the real library’s documentation. If the suggested package is absent, the agent should reconsider its implementation instead of repeatedly inventing nearby names until one installs successfully.
Common pitfalls
- Installing a name because generated code imports it confidently.
- Assuming a package is safe because the name exists.
- Allowing install scripts access to unrelated credentials.
Allowlisting existing dependencies can reduce exposure but is not a complete maintenance strategy. Approved packages can become vulnerable or compromised. Connect initial selection to ongoing updates, vulnerability review and reproducible release evidence.
Questions for operational review
Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.
- How is the intended package identity verified?
- What can installation scripts access?
- Who reviews newly introduced dependencies?
Articles linking here
References
Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.
- We Have a Package for You! Package Hallucinations by Code Generating LLMs ↗Accessed October 15, 2026
- NIST SP 800-218: Secure Software Development Framework v1.1 ↗Accessed October 15, 2026