A familiar product name is not a publisher identity
The package says Claude. Who gets to run code on your machine? Safe installation of AI coding tools starts by establishing that relationship, before granting the tool access to a repository or credentials. An npm name, a convincing description and a recognizable product word do not establish authorization from that product's vendor.
On 19 October 2026, GitHub published malware advisories for eight AI-themed npm package names listed below. Those advisories are a reason to investigate an installation, not evidence that the official Claude, Codex or ChatGPT products were compromised. This guide uses advisory records and official documentation; it does not claim a malware teardown or a sample execution. [1][2][3]
Flagged package names; do not install
claude-desktop-setup @decoopus/claude-setup
codex-setup chatgpt-desktop-setup
@decoopus/chatgpt-setup chatgpt-pro-activator
chatgpt-pro-setup-tool api-anthropicA takedown does not tell us what the payload did
The reviewed advisories identify malware but provide no behavioral analysis for this group. As of 20 October, the sources reviewed here do not establish which files were read, whether a particular credential store was targeted or what persistence was installed. Naming an infostealer family would fill the gap with a story rather than evidence. The packages share a theme; that alone does not prove one operator. [1][2][3]
Download totals would not solve that problem. A download can be automated, repeated or performed for analysis; it is not a confirmed execution or an affected person. For a team deciding its own exposure, the stronger evidence is the exact package and version in installation records, where it was installed, and whether code ran with access to valuable material. Record unknown execution state rather than treating missing telemetry as proof of safety.
Start at the vendor, then follow the distribution path
For Claude Code, Anthropic documents the official npm identity as @anthropic-ai/claude-code and also provides native installation channels. A similarly named setup package does not inherit that relationship. This is a method you can apply to any coding tool: begin at the vendor's documented installation page and follow its exact platform-specific channel, instead of selecting a package from a search result. [4]
The business process should make the verified choice easy to repeat. Keep a short approved-tool record with the documentation URL, distribution channel, expected publisher, selected version and update owner. Package pinning makes the chosen bytes or version repeatable; it does not establish that the initial choice was legitimate. Review the update path too, because tomorrow's installation may arrive without somebody copying a command again.
Proposed approved-tool record
Vendor documentation URL -> exact distribution identity
Version + platform -> expected artifact
Publisher / signing key -> trust anchor
Artifact hash -> recorded bytes
Update mechanism -> owner and review policy
Runtime permissions -> separately approved accessA checksum needs a trusted source of comparison
A checksum proves agreement between bytes and an expected digest. If an untrusted distributor supplies both, the agreement does not establish who produced them. Anthropic documents signed release manifests from Claude Code 2.1.89 onward, with older manifests carrying checksums without that detached signature. Verify the manifest against the documented signing-key fingerprint, then compare the chosen platform binary with the authenticated manifest. [4]
On Windows, the documented native binaries also carry an Authenticode signature. The inspection commands below do not run the executable. Check both signature validity and the expected publisher identity, Anthropic, PBC; an arbitrary valid signer is insufficient. These are documented verification steps, not a report that a binary was downloaded or verified for this article. [4]
# Inspect an already-downloaded binary; do not execute it
Get-AuthenticodeSignature -LiteralPath .\claude.exe |
Select-Object Status, SignerCertificate
Get-FileHash -LiteralPath .\claude.exe -Algorithm SHA256
# Compare signer and hash with the vendor's documented trust chain.A verified origin still needs a permission decision
Signature and provenance checks answer origin questions. They do not prove the code is free of malicious behavior or vulnerabilities. npm states this explicitly for provenance: it links a package to source and build information for review, rather than certifying harmlessness. Treat the result as one piece of evidence about the artifact, not a reason to give it every credential on the machine. [5]
My next question is what the installed program can reach. For an approved coding tool, review the repository contents, environment variables, credential stores and network access exposed to its process. Separate development access from production credentials and make additional permissions deliberate. That recommendation concerns execution authority in general; it is not a claim that the removed packages used any particular collection technique.
Does skipping install scripts make a CLI safe?
npm's ignore-scripts option suppresses package.json scripts during installation, but the documentation says explicitly requested scripts such as npm run still execute their intended command. It is not a sandbox for a program you subsequently launch. A team that blocks lifecycle scripts and then runs an unverified CLI has made another execution decision. Evaluate that decision separately. [6]
There is a practical compatibility cost as well: legitimate packages can need installation steps. The answer is an explicit, reviewed allowance with a reason, not disabling the control globally because one tool fails. Distinguish metadata inspection, installation and execution in the approval record. Each step gives different evidence and can expose different capabilities; none should quietly stand in for the next.
If you installed a flagged package, preserve the evidence
The malware advisories recommend treating a machine where the package was installed as compromised and rotating exposed secrets from a different computer. Follow that response guidance with your incident team: isolate the affected environment, preserve installation and process records, and establish which credentials it could reach. Removing the package alone is not proof that any resulting access or persistence is gone. [1][2]
That is deliberately different from asserting a specific payload. You can take containment seriously while remaining precise about what is unknown. Keep package identifiers and versions in the case record, alongside execution evidence and the credentials reviewed. Do not paste live secret values into a ticket or use an untrusted workstation to generate their replacements.
Make installation an engineering decision
I would ask a team to demonstrate one complete chain for an approved tool: the vendor points to this channel, the artifact matches this authenticated release, and the process receives this documented access. That chain can be reviewed by another engineer. A screenshot of a familiar logo or a package download counter cannot replace it.
This is secure software engineering work because the choices become part of onboarding, CI and update automation. If every developer has to reconstruct the trust decision alone, the organization has delegated a repeatable security control to a search result. Build the verified path once, name its owner, and keep its execution permissions narrow enough to defend.
Sources
Need this checked in your own product?
Custom software & website development