Your Developer Laptop Is Now an Attack Surface. Stop Running AI Agents on It.

The malicious Claude Code extension that appeared in Cursor’s marketplace should be a wake-up call for every engineering leader. On October 29, 2026, a maliciously modified version of Anthropic’s Claude Code extension was distributed through Cursor’s extension marketplace, potentially affecting up to 5,000 developers. The compromised extension attempted to install a persistent SSH backdoor, giving attackers a path to remote access. The malicious build was not developed by Anthropic, and no compromise of Anthropic’s systems has been confirmed.

Your laptop is your workstation. It should never be your AI agent’s execution environment.

TL;DR

• On October 29, 2026, a malicious build of the Claude Code extension (version 2.1.313) reached up to 5,000 developers through Cursor’s extension marketplace and attempted to plant a persistent SSH backdoor.
• A developer laptop holds production credentials, cloud tokens, SSH keys, source code, customer data, and VPN access. One compromised coding tool can expose all of it.
• AI coding agents execute code, install dependencies, and interact with untrusted content. On a laptop, each of those actions runs with the developer’s access.
• Keep using coding agents, and run their execution environments, including the agent itself, in isolated, remotely hosted sandboxes with VM-level isolation, restricted network access, and narrowly scoped credentials.
• Control Plane Sandboxes run in dedicated Kata Containers microVMs and use Control Plane’s Universal Cloud Identity, so an agent has no cloud keys to leak.

What happened in the Claude Code extension incident?

According to Cursor’s security notice, a maliciously modified version of Anthropic’s Claude Code extension was available in Cursor’s VS Code extension marketplace for about 11 hours on October 29, 2026, between roughly 2:27 a.m. and 1:35 p.m. Pacific time. The affected package is Anthropic.claude-code version 2.1.313. You are at risk only if you installed or updated to that version from Cursor’s marketplace during that window, which includes automatic updates. Cursor says at most 5,000 users were affected and that it will contact them directly.

The malicious build attempted to add an attacker-controlled SSH key to the developer’s authorized_keys file, enable the local SSH service, and open a reverse SSH tunnel. Cursor says the added key is labeled svc-telemetry. It made the tunnel persistent through a LaunchAgent on macOS and a scheduled task or Startup script on Windows, and StepSecurity and The Hacker News also report a cron entry on Linux.

Cursor says enabling SSH requires administrator rights the extension lacks on most macOS and Windows machines, so on those machines that step failed and the attacker could not log in through the tunnel. The extension still added the attacker’s key, installed persistence, and sent host details to the attacker, including the hostname, username, environment variable names, configured Git email, and public IP address.

Cursor states the malicious version was not developed by Anthropic and that it has no evidence other versions or the official distribution were affected. Cursor pulled the version, shut down its marketplace to audit it, and reports that no other extensions were tampered with. How the build was published under the extension’s name has not been publicly explained, as BleepingComputer notes, and no compromise of Anthropic’s systems has been confirmed. The Hacker News reports that Anthropic has published a clean version, 2.1.314.

The specific attack matters less than the pattern. A trusted developer tool, delivered through a normal marketplace, became a path into developer machines.

If you installed the extension, do this now

1. Follow the check in Cursor’s security notice to confirm whether you are affected.
2. If you are affected, disconnect the machine from the network before anything else.
3. Look for an entry labeled svc-telemetry in ~/.ssh/authorized_keys and, on Windows administrator accounts, in C:\ProgramData\ssh\administrators_authorized_keys. Remove any key you did not add.
4. Uninstalling the extension is not enough, because the payload leaves standalone persistence scripts. Use the remediation scripts Cursor publishes for macOS and Windows, or remove persistence by hand: ~/Library/LaunchAgents, /Library/LaunchAgents, and /Library/LaunchDaemons on macOS; Task Scheduler and Startup folders on Windows; crontab on Linux. Then stop any reverse SSH tunnel processes.
5. If you did not enable it yourself, turn off the SSH server: Remote Login on macOS, the sshd service on Windows or Linux.
6. From a clean device, rotate every secret the machine could reach: cloud credentials, SSH keys, API tokens, repository tokens, and package-registry publish tokens. Invalidate active sessions, and check your Git host for SSH or deploy keys you did not add.
7. Assess whether to rebuild the machine from a known-good state, then reinstall the extension at version 2.1.314 or later. Contact [email protected] with questions.

Why is a developer laptop such a big target?

Consider what sits on a typical developer’s laptop:

• Production credentials and cloud access tokens.
• SSH keys and access to private repositories.
• Customer data, internal documents, and proprietary source code.
• VPN connections into corporate infrastructure.

An attacker who gets code execution on that laptop inherits the developer’s access, and a persistent backdoor can keep that access after the malicious tool is removed.

Why do AI coding agents raise the stakes?

AI coding agents routinely execute code, install dependencies, and interact with untrusted content. Each of those is a path in:

• Executing code. Agents run builds, tests, and scripts. Malicious code runs with the developer’s permissions.
• Installing dependencies. Agents pull packages from public registries, where typosquatted and compromised packages appear regularly.
• Reading untrusted content. Agents read issues, web pages, and documentation. Instructions hidden in that content can steer an agent into running commands or sending data it should not.
• Running as an extension. The agent itself is software delivered through a marketplace. If that delivery channel is compromised, the agent is the attack, and it runs wherever the agent is installed.

Running all of that directly on a laptop gives every one of those paths the developer’s access. A remote sandbox helps only if the agent itself, not just its commands, runs there.

Laptop vs remote sandbox: what changes?

How should you run AI coding agents safely?

Keep the developer’s workflow. Move the agent’s execution somewhere a compromise stays contained. A practical checklist:

1. Run agents in remote sandboxes. Install the agent CLI or extension inside the sandbox, not in the local editor, and keep its tools and dependencies off developer endpoints.
2. Use VM-level isolation. A shared kernel is a weaker boundary for code you do not trust.
3. Restrict network access. Give the sandbox only the network paths the task needs.
4. Scope credentials narrowly. Use short-lived, least-privilege credentials, never long-lived keys copied into the environment.
5. Bring no laptop secrets in. Do not mount the home directory, forward the SSH agent, or copy ~/.aws, ~/.ssh, or .env files. Give each sandbox its own repository-scoped token, read-only by default.
6. Make environments disposable. Start each task from a known template and throw the environment away afterward.
7. Keep production separate. Sandboxes are for building and running untrusted code, not for serving production traffic.
8. Review before merge. Agent output still goes through code review and CI, and agent tokens cannot push to protected branches or edit CI workflows.
9. Log and audit. Record agent commands, outbound connections, and credential use, and alert on anything unexpected.

For a broader comparison of options, see the best AI agent sandboxes in 2026, and for why sandbox design matters to coding agents, read dumb sandbox vs smart sandbox for coding agents.

What are Control Plane Sandboxes and how do they help?

Control Plane Sandboxes are isolated, remotely hosted environments where AI coding agents run code, install dependencies, and use tools inside dedicated Kata Containers microVMs, away from developer laptops. Control Plane is the platform for running unbreakable apps and agents, and its Sandboxes are designed for exactly this problem: developers keep their familiar workflows, agents get isolated execution environments, and a compromised agent does not automatically inherit access to everything on a developer’s machine.

• VM-level isolation. Sandboxes run in dedicated Kata Containers microVMs.
• No cloud keys to leak. Sandboxes use Universal Cloud Identity to call AWS, GCP, and Azure services without storing credentials in the sandbox.
• Blueprint templates. Teams define templates with the tools an agent needs, such as cloud CLIs, Git CLIs, and coding agent CLIs, then start ephemeral sandboxes from them.
• Sized for the work. Sandboxes range from 2 to 16 or more CPUs, and each has a dedicated TLS endpoint.
• Idle behavior. Sandboxes auto-sleep when idle and spin back up in under one second.
• Private access when needed. Control Plane’s Cloud Wormhole gives sandboxes access to services in VPCs and private on-premises networks behind firewalls, without VPN clients to install.
• Familiar access. Developers connect with the Control Plane CLI command cpln sandbox connect from Cursor, over SSH, or in a browser IDE. See Getting Started with Sandbox.

Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. When an agent graduates from experiment to production, it runs as a regular workload on the same platform. Read how to let AI agents work on production infrastructure safely.

See how Sandboxes fit your agents: talk to the Control Plane team.

How much does a sandbox reduce the blast radius?

No isolation layer stops every attack. What a sandbox changes is how far an attack can travel. A compromised agent inside an isolated environment with narrowly scoped access is a contained incident. The same agent on a developer laptop can become a breach of your engineering environment.

Your laptop is your workstation. It should never be your AI agent’s execution environment.

Doron Grinstein, CEO, Control Plane

FAQ

Should AI coding agents run on developer laptops?

Not for execution. Coding agents run code, install dependencies, and read untrusted content. On a laptop they inherit everything the developer can reach: SSH keys, cloud tokens, source code, and VPN access. Run the agent’s execution environment in an isolated remote sandbox, install the agent there rather than as a local editor extension, and keep the developer’s machine for editing and review.

What should I do if I installed the malicious Claude Code extension?

Follow the check in Cursor’s security notice. If you are affected, disconnect the machine, remove any authorized_keys entry labeled svc-telemetry, remove the persistence scripts (uninstalling the extension is not enough), and turn off the SSH server if you did not enable it. From a clean device, rotate the credentials the machine could reach and invalidate sessions. Then consider rebuilding the machine from a known-good state and reinstall version 2.1.314 or later.

What is a sandbox for AI coding agents?

An isolated, disposable environment where an agent can run code, install packages, and use tools without touching the developer’s machine or production systems. Good sandboxes add VM-level isolation, restricted network access, and short-lived, narrowly scoped credentials.

Does a sandbox stop every attack?

No. A sandbox limits the blast radius. A compromised agent inside a sandbox can reach only what that sandbox is granted, not everything on a developer’s laptop, unless it escapes the isolation boundary. You still need dependency hygiene, code review, and least-privilege access.

How do Control Plane Sandboxes isolate AI agents?

Sandboxes run in dedicated Kata Containers microVMs. They start from blueprint templates, auto-sleep when idle, and use Universal Cloud Identity to call AWS, GCP, and Azure services without storing cloud credentials, so an agent has no cloud keys to leak.

Can developers keep their normal workflow with remote sandboxes?

Yes. Developers keep their editor and review flow and connect to the sandbox when they need a shell, for example with cpln sandbox connect from Cursor, over SSH, or in a browser IDE. The agent’s tools and dependencies live in the sandbox, not on the laptop.

Get started

Talk to the Control Plane team | Sign up free

Originally published on the Control Plane blog.