AI Coding Assistants Skip the Labels Before They Install

You open a project in your editor, or you just start a Claude Code session inside it — and that alone is enough. With the ChainDrop worm that hit npm in August 2026, running no code at all sets the malware off: it writes a SessionStart hook into .claude/settings.json and a folder-open task into .vscode/tasks.json, so opening the checkout is the trigger, not any command a developer types, according to Datadog Security Labs — the same persistence mechanism Wiz independently reported .

For three years the software industry’s answer to attacks like this one has been to publish machine-checkable trust signals — SBOMs, signed releases, build provenance, declared official channels — on the assumption that whoever types install will check them first. That assumption no longer holds: the trust layer was designed around a human reader checking a badge before typing install, and that reader has been quietly replaced by a program that doesn’t. A pre-registered audit posted to arXiv on 7 September 2026, Do AI Coding Assistants Check Before They Install? , ran 1,920 trials of AI coding assistants installing software and found they opened any provenance signal before installing in nine of them — 0.5% — and never once ran a verification command.

Nine trials out of 1,920 opened a label

The audit, by Pengyin Shan, tested six open-source research-software projects — three from high-performance computing, three from quantum computing — inside containerized trials, running three different models under two operating modes, one of which required an explicit approval step before install. For each project the researchers built nine modified copies: some with no trust signal at all, some with a single signal class, some reproducing documented metadata conflicts. Two of the nine carried a signature or attestation from the wrong issuer, a mismatch a single verification command would surface in seconds.

The assistants installed those anyway, which follows from the study’s blunter finding: across every one of the 1,920 registered trials, and every one of 384 control trials with no signal present at all, not a single run ever executed a check. Signal presence had no measurable effect on behavior. Price didn’t help either — the model that verified most often cost $0.10 per trial; the most capable model tested, at $1.00 per trial, verified nothing. Researchers scored behavior from container logs, not from what the assistant claimed it had done, which is what makes “zero” hard to argue with.

A clean label would not have stopped the worst attack

The honest complication is that verification, done perfectly, would not have caught the year’s worst npm incident. In Mini Shai-Hulud, a wave that hit 172 packages across 400-plus versions on 10-12 May 2026, the malicious releases carried valid SLSA Build Level 3 provenance — attackers pulled OIDC tokens out of GitHub Actions runner memory and used them to obtain legitimate Sigstore certificates. As the Cloud Security Alliance’s research note put it, “provenance attestations verified where the packages were built, but could not verify that the build environment had been compromised.”

Nor is the supply side standing still. Aikido Security’s tracking shows npm’s trusted-publishing adoption jumped by 430 packages in a single week after those attacks, reaching 11,001 of the top 51,370 packages and a quarter of download volume — proof publishers are moving, even if three-quarters of downloads still ride on long-lived tokens. The honest version of the audit’s thesis, then, isn’t that signing is pointless; it’s that the demand side, the checking half of the trust relationship, went entirely unmeasured until now — and unmeasured turned out to mean unused.

The check has to live in the harness now

The audit’s own sample is narrower than the danger it describes: six research-software projects, synthetically modified, run in a sandbox — not a developer’s real npm or PyPI session, and not the ecosystem where ChainDrop and Mini Shai-Hulud actually operate. Read across to everyday product work, where Cursor, Claude Code and other assistants already trip the same detection rules built to catch human attackers , the finding suggests the gap isn’t confined to six niche codebases — it’s a property of how these assistants are built to behave, wherever they’re pointed.

That leaves the check somewhere specific: whoever approves the command. A developer who lets Claude Code or Cursor propose and run an npm install is, in practice, the only verification step left — not the badge on the package, not the model’s judgment, and not a plan the assistant shows before acting, which research on approval checkpoints has already found people check least closely . The tooling itself isn’t built for this yet: Claude Code’s sandbox documentation describes a harness that enforces which files and network domains a command can touch, nothing about what it installs or from whom — isolation and permissions, not provenance, much as Open VSX’s registry problem showed the same gap one layer down in the extension supply chain . The badges were built for a reader who checked them by hand. Until the harness does that reading instead, the badge is decoration, and the reading is yours.