Used Claude Code in Cursor? Check the install, then the machine

If you installed Claude Code through Cursor on Windows or macOS, check the installation history before assuming an extension update finished the job. Cursor identifies modified Anthropic.claude-code versions 2.1.312 and 2.1.313 distributed through its marketplace on October 29, roughly 2:27 a.m.–1:35 p.m. Pacific.

This matters to the machine you build with, and potentially the accounts it can reach. The practical question is whether that particular installation matches the affected distribution route, followed by what evidence would justify trusting the workstation again.

What is confirmed, and what is not

The incident window was October 29; the October 30 update clarified scope. Sources were checked again on November 2. This is a recovery guide, rather than a new November disclosure.

Cursor says Anthropic did not develop the malicious packages and reports no evidence affecting other versions or the official distribution. It describes attempted persistent SSH access, including persistence that can remain after uninstalling. A familiar extension name therefore does not establish its provenance, and this report does not establish that everyone using Claude Code was affected.

BleepingComputer reports that the malicious code ran when the extension loaded, without requiring interaction with Claude Code. “I never sent it a prompt” is consequently an inadequate way to rule out this installation path.

The steps below are our editorial workflow for organizing the response. They are not results of testing your computer, a replacement for the vendor’s current instructions, or a guarantee of complete remediation.

First, choose the right investigation path

Start with evidence you already control: your extension-management records, installation history, backups of configuration, and any endpoint monitoring maintained by your administrator. Avoid changing the machine just to make a screenshot look clean.

These categories distinguish an evidenced match, an evidenced difference, and an unanswered question. They are not automated verdicts. If a record is missing, write “unknown,” along with who will investigate it.

Make an installation record before relying on the display name

Write down which computer and operating-system account you are investigating. Then record the editor, extension identifier, observed package version, installation source, and the dates your available records cover. Record where each observation came from.

A screenshot of the current version answers a current-state question. An installation log can answer a historical question. Keep both, and avoid silently substituting one for the other. If you use several computers, repeat the record for each one; evidence from your laptop does not establish what happened on a separate development machine.

For a small team, assign one person to collect this information and one person to make the recovery decision. For a solo builder, the second person may be a trusted technical responder. The useful handover is a clear account of what is known, rather than an unsupported conclusion that the machine is safe.

Do not paste API keys, environment-file contents, private SSH keys, or session tokens into a support message or an AI chat. Identifiers, timestamps, and redacted evidence should let the owner start investigating without creating another copy of the sensitive material.

Separate marketplace containment from workstation recovery

Cursor reports rebuilding its marketplace and taking the attacker’s server offline. It still directs affected owners to investigate, remove unauthorized access and persistence, and assess rebuilding the host.

Treat those as different work items. A provider can restore its distribution service while an individual owner still has a recovery task. Similarly, removing the extension changes the installed application list; it does not, by itself, document the state of every change that ran outside that extension.

Use the current vendor notice as the starting point for technical response. It links platform-specific checks and remediation material. Have a qualified responder review that material and decide how to preserve evidence, contain the affected computer, remove confirmed changes, and determine whether rebuilding is appropriate. We have not executed those scripts or reproduced the malware for this article.

Avoid turning a single indicator search into a certificate of safety. A positive match deserves investigation; an absent match answers only the particular question that search covered. Record which evidence was available, which period it covered, and what remained unavailable.

Cursor notes that SSH enablement often failed without administrator rights, but still instructs affected users to remediate. Do not use a failed step in the attack chain as your entire recovery decision.

Give app credentials their own response record

Cursor advises rotating credentials and sessions accessible from affected hosts using a trusted system. It warns that collecting environment-variable names does not rule out later credential access.

For an app builder, the useful follow-up is a map of authority. List the services the affected development account could reach, the credentials or sessions involved, and the administrator who can replace or revoke each one. Scope this to evidenced or reasonably reachable access; the table below is a planning aid, not a claim that these services were compromised.

Store identifiers and decisions in this record, never secret values. Keep production and test environments separate so a successful staging check is not mistaken for evidence about production.

For each replacement, identify the applications and jobs that depend on it. Agree on the provider-supported replacement and revocation sequence, verify that the intended application works with the new access, and confirm the old access has been retired. Record unresolved sessions or integrations explicitly rather than calling the entire task complete after changing one key.

Define the evidence needed before returning to normal work

A useful closure note connects every action to an observation. “We ran cleanup” records an activity. It needs a second entry explaining what the responder checked afterward and which limitations remain.

Ask for a short account covering the affected installation, the host recovery or rebuild decision, unauthorized access found and addressed, credential and session decisions, and application checks after those changes. Give each unresolved item an owner. Where evidence cannot establish whether something happened, keep that uncertainty visible.

Choose harmless application checks that exercise the affected dependency without exposing real customer material. For example, a synthetic staging workflow can confirm that a deployment can read its expected test configuration after a credential change. It cannot establish that no historical access occurred, or that a workstation investigation is complete.

The distinction matters when your app still appears to work. Availability, account control, and confidence in the development computer are separate questions. Require evidence for each question you actually need to close.

A small, synthetic handover example

Imagine a solo builder with one development laptop, a staging database and a production deployment account. This is an invented example, not a reported victim.

The builder cannot recover reliable installation history, so exposure stays unresolved. A responder owns the workstation investigation and records its eventual recovery decision. The deployment-account owner separately reviews reachable sessions and credentials from a trusted computer. The database owner records which environment each credential permitted and how any retired access was invalidated.

Afterward, a staging check confirms the app’s expected workflow still functions. The handover records that result alongside the recovery evidence and remaining gaps. Nobody substitutes “the app loads” for the responder’s workstation conclusion.

Once this incident response is complete, return to the vibe coding security checklist for the app itself. The workstation investigation and your application’s security review have different evidence and owners.

Questions to keep open

The sources used here do not establish the attacker’s exact publishing mechanism, a current victim count, or whether your installation executed the payload. We make no claim of firsthand testing or successful recovery on a reader’s machine.

Before acting or publishing a follow-up, reopen the current Cursor notice. Preserve the original installation evidence and unresolved questions even when the next update gives a clearer answer.