Cursor cloud agents are getting a notable update: they can now run in isolated virtual machines with full development environments.
It is widely known that Agents tend to plateau when they can’t actually run the software they’re changing. By giving each agent its own VM, Cursor is aiming for agents that can build, test, and validate their own output before handing work back as a PR.
Cursor frames this as a shift from agents that primarily generate diffs to agents that can operate more like autonomous contributors. Internally, the company says more than 30% of merged PRs are now created by agents running in these cloud sandboxes.
Why isolated VMs change the agent workflow
Cursor positions local agents as easy to start with, but constrained by the realities of a developer machine: resource contention, conflicts between parallel tasks, and the general friction of running tests and UI checks locally. Cloud agents avoid that by running each agent in an isolated VM, which also makes it practical to run many agents in parallel.
Just as important, Cursor says cloud agents can iterate until they’ve validated output—not merely produce a first pass. Each run can emit artifacts like videos, screenshots, and logs, intended to make review faster and more concrete than scanning a diff alone.
Merge-ready PRs, plus “computer use” artifacts
The updated flow goes beyond code changes: cloud agents can onboard onto a codebase, generate merge-ready PRs, and produce artifacts that demonstrate behavior. Cursor also says it’s possible to control the agent’s remote desktop to try the modified software and make edits directly, without checking out the branch locally.
In at least one internal example, Cursor notes the agent also handled typical PR chores: it rebased onto main, resolved merge conflicts, and squashed to a single commit.
Examples Cursor highlights from internal use
Cursor outlines several patterns where cloud agents have been useful internally:
Building features (plugins and source links)
Cloud agents helped build functionality related to plugins and the Cursor Marketplace. Cursor shares an example prompt describing a system to track component source files (like .md files, hooks.json, and .mcp.json) and generate GitHub links, tested locally against [https://github.com/prisma/cursor-plugin.](https://github.com/prisma/cursor-plugin`.) The agent then recorded itself navigating the UI and clicking components to verify the links.
Reproducing a vulnerability from Slack
Cursor describes starting a cloud agent directly from Slack to triage a clipboard exfiltration bug. The agent reportedly built an HTML demo page using an exposed API, ran a backend server to host it locally, and used Cursor’s in-app browser to demonstrate the flow—capturing a video and screenshot, and committing the demo file.
Quick fixes with UI verification
Another example: swapping a static “Read lints” label for a dynamic one based on lint results—“No linter errors” vs. “Found N errors”—including styling aligned with existing CSS. Cursor says the agent tested both a file with type errors and a clean file, and recorded a video showing the results.
End-to-end UI walkthrough testing
Cursor also describes running a cloud agent against cursor.com/docs for a 45-minute walkthrough, covering UI components like navigation, search, theme switching, and feedback dialogs, followed by a summary of what was tested.
Toward “self-driving codebases”
Cursor ties this release to a longer-term direction it calls self-driving codebases: agents that don’t just propose changes, but merge PRs, manage rollouts, and monitor production. Near-term, Cursor says the focus is on coordinating work across many agents and building models that learn from past runs.
More details are available in the cloud agent docs, and onboarding is referenced at cursor.com/onboard.