Cursor Cloud Agents can now run on Daytona sandboxes. Each request gets its own Linux container, Linux VM, or Windows environment, created on demand from a snapshot you define and deleted when the worker exits.
Cloud Agents normally do their work on machines Cursor hosts: cloning the repository, editing files, running builds and tests. Self-Hosted Machines splits that arrangement; the agent loop and model access stay with Cursor, but the machine that executes the agent's commands runs wherever you put it. That matters when code can't leave your boundary, or when a run needs tools, dependencies, or network access that a hosted machine doesn't have.
This integration puts those machines on Daytona. We built a reference implementation that handles the whole lifecycle, along with a guide that walks through it.
How it works
Start a Cloud Agent in Cursor and select one of your team's Self-Hosted Pools (see the Cursor Self-Hosted Pool docs for more details).
You run Cursor's agent worker controller, on a machine you control, pointed at that pool. When someone starts an agent there, the controller claims the request and calls our spawn helper. The helper creates a sandbox from your snapshot, sets the requested repository as the workspace origin, and launches the Cursor worker inside. Cursor mints a short-lived GitHub token for the run, and a checkout hook fetches the requested branch into the workspace. From then on the agent works in the sandbox like it would on any other machine.
Sandbox lifecycle
Every claimed request gets its own sandbox and its own worker process. Follow-up messages reuse that worker while it waits within the idle timeout, so the workspace stays where the agent left it. A monitor on the controller host deletes the sandbox after the worker exits. If the worker fails to start, the spawn helper releases the request and deletes the sandbox, and Daytona's auto-stop and delete-on-stop settings act as a fallback if the monitor itself goes away.
Linux and Windows
Pools are per-snapshot, and the integration covers three sandbox classes: Linux containers built from the included Dockerfile, Linux VMs built from Daytona's daytona-vm-medium snapshot, and Windows VMs built from windows-medium. The VM builders provision a temporary sandbox, capture a cold snapshot, then boot a fresh verifier and confirm the worker starts before calling the snapshot ready. Snapshot names are derived from the build recipe, so an unchanged recipe reuses the existing snapshot. Any additional toolchains or dependencies can be baked into the snapshot if needed.
Keys stay on your host
The controller host holds both API keys. The sandbox receives the Cursor service-account key, which the worker needs, but never the Daytona key. Snapshots contain no API keys, the sandbox needs no inbound port, and nothing stores a long-lived GitHub credential: the checkout hook fetches with the token Cursor minted for that run only.
Get started
Self-Hosted Pools require a Cursor Enterprise team and a service-account API key, and the controller ships in the lab channel of the Cursor CLI. Read the Cursor Self-Hosted Machines on Daytona guide for the full setup, and Cursor's Self-Hosted Machines documentation for the official feature documentation.
