Did Claude And Codex Install Unclaimed Packages From llms.txt?

August 28, 2026

Researchers say AI coding agents followed trusted llms.txt instructions into unclaimed package names. Here is what is confirmed, unclear, and worth auditing.

Researchers say Claude, OpenAI Codex, and Nous Hermes followed trusted website instructions into package names that nobody owned. Their controlled packages only sent back installation beacons, but one callback arrived from a Fortune 500 network in under four minutes. The result does not prove the agents were breached by llms.txt alone. It shows how official documentation can become a software supply-chain input when an agent has permission to install code.

Watch The 30-Second Summary

Watch this video on YouTube

The most important question is not whether llms.txt is good or bad. It is whether any document—official or otherwise—can make an AI agent install a dependency without independently verifying the package namespace, publisher, version, digest, and requested authority.

What Is Confirmed

Security researcher Alon Hertz published the primary report on August 26, 2026. The researchers scanned agent-facing documentation, found instructions that referred to unclaimed package names or internet destinations, registered a small set of those names, and published inert packages containing a callback beacon.

The first callback arrived in under four minutes, according to the report. A second Fortune 500 callback arrived within an hour, followed by additional callbacks from enterprises and startups. The controlled packages did not deploy persistence, steal files, or install a destructive payload.

Ars Technica's independent report says recorded parent-process chains identified Claude, OpenAI Codex, and Nous Hermes among the coding agents involved. That is evidence about particular observed executions, not proof that every version, configuration, or normal session of those products behaves the same way.

The researchers also described a separate, real malicious-package case involving Clerk documentation and the bare command clerk-next-fix-auth-protection. Google's OSV record MAL-2026-11069 confirms that the public npm package used preinstall and postinstall hooks to send the installer's username, hostname, working directory, and timestamp to an outside server. The primary report says Clerk responded and addressed the documentation after disclosure.

That malicious package was not created by the researchers. It is a separate example they found while examining the same trust pattern.

What Is llms.txt?

llms.txt is an emerging community convention for publishing concise, AI-readable information about a website. The current Answer.AI proposal describes a Markdown file that can summarize a site, give agents guidance, and link to detailed machine-readable pages. It is intended to help an agent find reliable documentation at inference time.

Google's Lighthouse documentation calls llms.txt an emerging convention and includes an audit for whether a site publishes one correctly. OpenAI, Anthropic, Google, documentation platforms, software vendors, and many smaller projects now publish agent-readable files or Markdown documentation.

The file is not an executable format. It cannot run a package by itself. The risk appears when a high-authority agent reads a line such as pip install company-sdk or npx company-tool, treats the official host as sufficient proof, and executes the command.

The chain has four separate decisions:

Decision What must be trusted
Read the file The website and fetched content
Interpret an install command The documentation's current accuracy
Resolve the package name The public registry and namespace owner
Execute the package The agent's shell authority and the package's install behavior

HTTPS can authenticate the website connection. It does not prove that an npm, PyPI, RubyGems, NuGet, crates.io, or Packagist name belongs to the same organization.

How The Controlled Test Worked

The researchers did not need to compromise a vendor website. They started with public instructions that already named destinations no one had claimed.

Their reported sequence was:

  1. Find an official llms.txt, llms-full.txt, or related documentation path containing an install or setup instruction.
  2. Confirm that the named package, domain, or hosted subdomain was unclaimed.
  3. Register a small number of those destinations.
  4. Publish an inert package that sent a minimal installation callback.
  5. Wait for an agent or user to follow the existing official instruction.
  6. Record the callback and parent-process chain without installing persistence or taking data from the target.

The primary report also describes a controlled prompt test. Five frontier configurations across two agentic command-line tools received the same general request to build a Node.js project using a named vendor's SDK. The researchers say each configuration had 100 attempts and that agents independently found the vendor documentation, reached llms.txt, and installed the unclaimed name in at least some runs.

The full per-configuration results are shown as an image in the report rather than a machine-readable table. Readers should not infer a product-by-product success rate that the text does not supply.

The Published Counts Do Not Match

The primary write-up and Ars Technica give different corpus numbers.

Measure Primary report Ars Technica
Live domains scanned 6,214 6,214
llms.txt files 8,565 8,265
Unclaimed references 237+ artifacts 227 commands across 120 sites

Those figures may represent different filtering stages, revisions, or definitions. Neither source reconciles the discrepancy. Until the researchers publish a dataset or correction, the safest conclusion is qualitative: they found hundreds of risky references across more than one hundred sites, but the exact total is unsettled.

This does not erase the callback evidence. It does lower confidence in quoting one precise corpus total as definitive.

What Is Still Unclear

Which Agent Configurations Ran The Installs

The press report names Claude, Codex, and Hermes from captured process ancestry. The public primary report does not identify every version, permission mode, prompt, operating system, workspace policy, or approval state behind each callback.

That missing configuration matters. Anthropic's Claude Code CLI reference documents allowlists, denylists, permission modes, and a --dangerously-skip-permissions option. OpenAI's current model guidance tells developers to define autonomy and approval boundaries explicitly. A read-only or plan-only agent is not equivalent to an agent permitted to run arbitrary installation commands.

How Many Companies Were Actually Affected

The researchers withheld company names while disclosures and remediation were underway. They describe a few dozen callbacks, including Fortune 500 systems and startups, but the public material does not provide raw telemetry, exact organization counts, or independent validation for every callback.

A callback proves that code from the researchers' package executed somewhere. It does not by itself establish who approved the action, whether a human initiated the install, whether the environment was production, or what data the package could have accessed.

Whether Any Controlled Target Lost Data

The researchers say their packages were inert except for the callback. They report no persistence and no data exfiltration in the experiment.

That boundary should remain prominent. The test demonstrates an execution path with meaningful potential impact. It is not a report that the researchers installed ransomware, stole corporate source code, or maintained access inside the companies that called back.

Whether The Malicious Clerk Package Infected Users

OSV confirms that the package was malicious and that its install hooks sent system details to an attacker-controlled endpoint. The public sources reviewed for this article do not provide a victim count, a complete access log, or proof that a particular AI agent installed it in a confirmed incident.

The malicious package makes the risk concrete. It still does not establish the scale of real-world compromise.

Whether llms.txt Is The Only Risky Surface

It is not. An agent can find install instructions in a README, ordinary documentation page, issue, forum post, support ticket, email, generated search result, or copied code block. Removing llms.txt without changing the execution policy only moves the same decision to a different content source.

Why This Is A Supply-Chain Problem, Not Just Prompt Injection

Classic prompt injection involves untrusted text trying to override an agent's instructions. This case can work without an obviously malicious instruction. The content may be official, accurately transmitted over HTTPS, and sincerely intended to help.

The failure appears later: the documentation names a package that the publisher does not control, and the agent resolves the name from a public registry.

That is closer to dependency confusion and namespace abandonment than to a model jailbreak. The agent accelerates the chain because it can discover the instructions, run the package manager, and continue without a human noticing that the package's publisher is unrelated to the documentation host.

Three facts can all be true at once:

The DOCS Check Before An Agent Installs Anything

Use DOCS as a short audit before an AI agent executes an installation command found in documentation.

D — Destination Ownership

Verify the registry namespace, publisher identity, repository, and domain ownership. An organization controlling vendor.com does not automatically control an unscoped package called vendor-tool.

Prefer scoped packages where the registry supports them, such as @vendor/tool, but still verify that the scope belongs to the expected publisher.

O — Origin Versus Artifact

Treat the documentation origin and software artifact as separate trust decisions. Check whether the official repository or release page links back to the exact package name.

A search result, README, llms.txt, or vendor page is evidence about the instruction. It is not a cryptographic binding between that instruction and the downloaded bytes.

C — Cryptographic And Version Pinning

Pin an exact version and, where the ecosystem supports it, verify a lockfile, digest, signature, provenance statement, or approved internal mirror. Review install scripts before allowing them to run.

Commands such as npx package-name can resolve and execute a public package dynamically. A convenient one-liner deserves more scrutiny, not less.

S — Scope And Sandbox

Ask what the install process can read, write, execute, and send over the network. Run untrusted setup in a disposable environment without production credentials, SSH keys, cloud tokens, browser sessions, or access to sensitive repositories.

Make package installation a distinct approval category. A broad permission for npm, pip, or shell execution can silently turn a documentation-reading task into arbitrary code execution.

What Developers And Security Teams Should Do Now

Audit Agent-Facing Documentation

Inventory llms.txt, llms-full.txt, Markdown mirrors, READMEs, setup guides, and generated integration pages. Extract package names, domains, hosted subdomains, container images, curl targets, and one-line installers.

For every destination, confirm that the organization still controls it. Recheck continuously because a safe domain or package today can expire, transfer, or be removed later.

Separate Fetching From Execution

Let an agent read documentation without automatically granting the ability to install dependencies. Require a human or deterministic policy to approve the exact package, publisher, version, and registry.

Do not approve a generic command pattern such as every npm install or pip install just to reduce prompts. Narrow rules to known packages and known tasks.

Use An Approved Registry Or Mirror

Enterprise environments can restrict package installation to an internal registry, allowlist, or repository manager. That does not guarantee a package is safe, but it creates a control point where ownership, provenance, scanning, and retention policies can be enforced.

Block Install-Time Network Access When Possible

Many package ecosystems allow lifecycle hooks or build steps to execute during installation. A disposable environment with limited outbound access can reduce the damage from an unexpected hook.

Test the workflow before relying on it. Some legitimate packages need downloads during installation, so an unexplained global allow can quietly return.

Log The Whole Decision Chain

Record the source URL, exact instruction text, resolved registry, package publisher, version, digest, approval, process tree, and outbound connections. A shell transcript without the original source can make the incident look like an ordinary developer install.

What This Does Not Prove

This research does not prove that:

The demonstrated risk requires a reachable instruction, an unclaimed destination, an agent or human that resolves it, and enough execution authority for the package to run.

What This Means For OpenVeil

OpenVeil is a hosted, privacy-focused AI workspace for adults. Normal chat history is stored in the browser rather than as a normal server-side chat-history record. Active prompts, uploads, searches, selected local history, and media still require processing by OpenVeil and necessary providers.

OpenVeil is not a coding-agent sandbox, package-registry scanner, dependency firewall, or endpoint-security product. It does not audit llms.txt, verify package ownership, approve Claude Code or Codex actions, or protect a workstation after arbitrary code runs.

The OpenVeil path is narrower. If you want conversational AI help without giving a coding agent authority to install packages or execute shell commands, you can try OpenVeil. Do not paste secrets or material you are not authorized to send to a hosted service.

Frequently Asked Questions

Did Claude And Codex Really Install Unclaimed Packages?

According to the primary research and Ars Technica, controlled packages received callbacks from corporate environments, and captured parent-process chains implicated Claude, OpenAI Codex, and Nous Hermes. The public evidence does not identify every version, permission mode, approval state, or company involved.

Was This A Prompt-Injection Attack?

Not necessarily. The controlled prompt asked agents to use a vendor's documentation and SDK. The dangerous step was resolving an official instruction to a package name the vendor did not own. That is a documentation-integrity and software supply-chain failure even when no malicious prompt is present.

Is llms.txt An Official Web Standard?

It is an emerging community proposal, not a ratified W3C or IETF standard. It is widely implemented enough that coding agents, documentation platforms, software vendors, and Google's Lighthouse tooling recognize it.

Can An llms.txt File Execute Code By Itself?

No. It is Markdown text. Code runs only when an agent or person follows an instruction and a tool such as npm or pip resolves and executes the referenced package.

Is HTTPS Enough To Trust An Install Command?

No. HTTPS authenticates the connection to the documentation site. It does not prove that a separately resolved package or domain belongs to that site owner.

Should Companies Delete Their llms.txt Files?

Not as a complete fix. Companies should audit every referenced destination, remove or correct unowned names, bind instructions to verifiable artifacts, and treat agent-facing documentation as security-sensitive. The same risk can exist in ordinary documentation and READMEs.

Does OpenVeil Prevent This Attack?

No. OpenVeil does not audit packages, control coding agents, or secure a local shell. Its documented privacy boundary is browser-local normal chat history in a hosted AI workspace, not protection against software supply-chain compromise.

Bottom Line

The research presents a credible warning: official documentation became an execution input, and AI coding agents reportedly installed packages that the documentation publisher did not own. The controlled packages were inert, the affected companies remain unnamed, and the published corpus counts conflict. Those limits matter.

The practical lesson is stronger than a single headline. Do not let the authority of a website automatically transfer to a package name. Verify ownership, pin the artifact, isolate installation, and make execution a separate approval decision.

llms.txt can remain useful. It must be maintained like code because, once an agent can act on it, stale documentation may have code-like consequences.

Sources

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.