Cursor Cloud Agents now run on Superserve

Your team starts Cloud Agents the same way as today, from the Cursor app, Slack, GitHub, or Linear. What changes is the machine underneath: one you configure, that keeps its state between turns, and that stops costing you while the agent waits.

If you don't need to configure or control that machine, Cursor's hosted machines work well, and you should keep using them. If you do need control, but don't want to run and patch a fleet of machines to get it, that's what this integration is for.

Configure the machine once

With Cursor's Self-Hosted Machines, Cursor runs the model and the agent loop, and a worker on your machine runs the tool calls: the clone, the edits, the builds, the tests. On Superserve, every request gets its own Firecracker microVM, booted from a template you define.

The template is where your environment lives. Put your language runtimes, internal CA certificates, and a primed package cache in it once:

typescriptCopy
await Template.create({
  name: "cursor-worker",
  from: "ubuntu:24.04",
  steps: [
    { run: "apt-get update && apt-get install -y ca-certificates curl git" },
    { run: "curl -fsS https://cursor.com/install | HOME=/root bash" },
    { run: "ln -sf /root/.local/bin/agent /usr/local/bin/agent" },
  ],
})

Every worker boots from that snapshot with the full filesystem already in place, so nothing gets downloaded or installed when a request comes in. When your toolchain changes, you rebuild the template once instead of patching every machine in a fleet.

Stateful, and you only pay while it works

Agents tend to work in bursts, with long waits in between. An agent might open a PR in the afternoon and not hear anything until a reviewer leaves comments the next morning. If the machine is deleted in the meantime, the follow-up starts over with a fresh clone and a fresh install, and if it's kept running, you're paying all night for a machine that's only waiting for one comment.

Neither is great. So we pause it.

In the guide's setup, a worker exits after 10 idle minutes and the monitor deletes its sandbox. Set CURSOR_WORKER_HIBERNATE=true and give the pool a reconnect window, and the monitor pauses the sandbox instead, which is exactly the case Cursor's hibernation support was built for. The pause saves the whole VM, including memory, running processes, and disk, and a paused sandbox isn't billed for compute. When the follow-up arrives, the same sandbox resumes in under 50ms with the checkout and build cache right where the agent left them, and if nobody comes back, it's deleted after 24 hours by default.

Control what it can reach

An agent reads a lot of text you didn't write: issues, READMEs, log files, dependency code. Sometimes one of those contains instructions.

Say a prompt injection hidden in an issue tells the agent to send its environment to a server somewhere. The agent wouldn't need to escape the sandbox to do it, because the Cursor worker authenticates with your service-account key and the agent's commands run as the same user. Whatever the worker can read, including that key, the agent can read too, and a network connection is all it takes to send it out.

Hardening the image doesn't change that, and neither does a monitoring tool on the worker, since it runs with the same permissions as the code it's watching. Two things do help: limiting where the machine can connect, and recording what it tried somewhere the agent can't reach.

Set CURSOR_WORKER_ALLOW_OUT and each sandbox can reach only the hosts you list, typically Cursor, your Git host, and your package registries. Private, link-local, and loopback addresses are always blocked.

Every HTTP and HTTPS connection the sandbox attempts to a public address goes into a network log that Superserve keeps outside the VM, so code inside the sandbox can't see or change it. Blocked attempts include the rule that stopped them. If the injected upload targets a host you didn't allow, it fails, and the log shows exactly what was tried:

typescriptCopy
const { events } = await sandbox.getNetworkLog({ verdict: "blocked" })
// host, verdict: "blocked", and matchRule: the rule that stopped it

Try it

The guide walks through the Cursor admin settings, the worker template, the egress allowlist, and hibernation. The reference implementation is in TypeScript and Python. If something doesn't work the way the guide says, open an issue.