A familiar extension name is not enough to establish what was installed. Record the distribution path and version before rollout.
Before approving an AI coding extension, record its exact identifier, version, installation source and update path. A familiar product name leaves too much unresolved about the software that will run on a developer’s machine.
The latest Cursor marketplace incident makes that distinction concrete. On October 29, 2026, Cursor reported malicious copies of `Anthropic.claude-code` versions 2.1.312 and 2.1.313 distributed through its extension marketplace for Windows and macOS. Cursor says the affected packages were available from about 2:27 a.m. to 1:35 p.m. Pacific Time that day and were not developed by Anthropic. It removed them and later rebuilt and reopened the marketplace. Read Cursor’s notice, updated October 30.
Keep the incident’s scope clear
Microsoft’s October 30 analysis says the malicious packages were not distributed through Microsoft’s Visual Studio Marketplace and that Anthropic confirmed its own systems were not compromised. That matters when deciding what to investigate. The extension name alone cannot identify which installation was exposed. Microsoft’s original analysis describes the affected distribution channel and package behavior.
The analysis describes attempts to establish persistent SSH access and collect host information. Whether remote access succeeded depended on the host and server configuration. Malicious files or persistence could remain even when the connection failed. Treat a failed connection and a clean machine as separate conclusions requiring separate evidence.
Make the installation record useful
For a team evaluating coding tools, a practical improvement is a short installation record. Keep these fields together:
- Purpose: what work the extension is approved to help with.
- Identity: its exact identifier and publisher, checked against the developer’s own documentation.
- Distribution: the marketplace or download address actually used.
- Version: what was installed and when it last changed.
- Update path: how updates arrive and whether the team can reconstruct that history.
This is a recommendation for keeping decisions traceable, not a claim that a checklist would have prevented this incident. Even an approved distribution service can have a security failure. The record should make it easier to compare a vendor’s notice with the software the team actually installed.
For example, “Claude Code approved” leaves the installation route unclear. A record containing the extension identifier, marketplace, version and installation date gives an investigator something specific to check. Keep that record in an appropriate internal system without adding credentials or unnecessary personal information.
Use the notice to investigate, not to improvise cleanup
If an installation matches the affected scope, use the vendors’ current guidance with the team responsible for endpoint security. Microsoft recommends preserving evidence and reviewing installation, process, network and persistence information. It explicitly warns that a missing marker alone should not replace that review.
Cursor also warns that uninstalling the extension may leave standalone persistence behind. Avoid assuming that removal settles the incident. The linked notices provide the technical checks and remediation details; a general article cannot establish whether a particular machine was affected or recovered.
For the next tool review, ask one concrete question: can we identify exactly what was installed and where it came from? Answering that before rollout gives the team a better starting point when a supplier publishes a security notice.