What Cursor Cloud Agents Can Do: Capabilities and Limits

Each cloud agent runs in its own isolated VM with a full desktop environment, so it can use a mouse and keyboard to control the desktop and browser the way a human developer would. That means it can start a dev server, open the app in a browser, click through UI flows, and verify a change works before it pushes a pull request.

What separates this from the agent in your editor turns out to be less the desktop than the approvals. A cloud agent runs every terminal command without stopping to ask, so it can sit on a failing test and keep trying while you do something else, where the foreground agent waits on you each time. That same property is what Cursor's own security docs name as the exfiltration risk, since a prompt injection has no approval step in its way, and the security and network page works through what to do about it.

Check whether your repo qualifies before you plan a workflow around it. Computer use is supported for repos with Dockerfiles based on Debian or Ubuntu distributions, and anything else is a support request. The check is narrower than that sounds, though, because what it turns on is the base image your Dockerfile starts from. A repo with no Dockerfile at all runs on Cursor's default Ubuntu machine, so the caveat probably never reaches it. The team switch for computer use lives in Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. settings and is available to enterprise teams only.

Agents create artifacts such as screenshots, videos, and log references to demonstrate what they did, and those artifacts attach to the pull request. You can validate a change from the PR itself without checking out the branch locally.

You can also opt in to embed artifacts directly into GitHub pull request descriptions. Enable the Allow posting artifacts to GitHub setting in the Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. dashboard to turn this on.

Whether unguessable counts as protection enough depends on what ends up in the picture. A recording of an internal admin flow is a different proposition from a screenshot of a marketing page, and the setting covers everything that follows it.

Which way to set it splits on who your reviewers are. Two or three people who all live in Cursor will open the agent anyway, so the artifacts attached to the PR are enough and the public URLs buy them nothing they did not already have. Once review pulls in people who never open Cursor, a recording has to be in the description to get watched at all, and the public URLs are the price of that.

If artifacts stop showing up on your PRs, start with egress. Uploads go to a host of their own, and blocking it drops the artifacts while the rest of the run carries on looking healthy. The security and network page has the host to allowlist.

Yes. You can take control of the agent's remote desktop to interact with the software it is building, then hand control back to the agent at any time to let it keep working.

Cloud agents run in a remote VM that can be onboarded with your repo, dependencies, tooling, and setup scripts. Because that VM mirrors your environment, you can test changes directly in it instead of checking out the branch on your local machine.

The VM profile a cloud agent gets by default has capped memory and CPU. Raising them is an Enterprise support request today, and Cursor lists self-serve resource configuration as coming soon. Which makes the takeover good for a flaky UI flow you want to watch yourself, and a poor home for the heavy build you were avoiding locally.

Cloud agents can use MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. (Model Context Protocol) servers configured for your team, which gives them access to external tools and data sources such as databases, APIs, and third-party services during a run. Add and enable servers through the MCP dropdown at cursor.com/agents. Cloud agents support OAuth for servers that need it, and OAuth is per-user, including for servers shared at the team level.

You can add custom MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. servers using either HTTP or stdio transport; SSE and mcp-remote are not supported. MCP configurations are encrypted at rest, and the sensitive fields below are redacted after saving and cannot be read back by any user.

Cursor recommends HTTP over stdio. The table below contrasts where each transport runs and what credentials the agent's VM can reach, which is the deciding factor for most teams.

The caption under that table carries the part that costs time. Cursor cannot tell whether a stdio server will start until a cloud agent launches, so a missing binary or a wrong path only shows up once the run is under way, and every attempt at a fix means booting another agent to see. Nothing in the HTTP path depends on the VM environment that way.

Guidance about remote MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. servers, including our own for the desktop app, tends to end in the same place: a remote server is a URL, over streamable HTTP or SSE. Cloud agents take only half of that, since SSE and mcp-remote are both rejected, which makes a vendor whose sole documented remote endpoint is SSE a blocked integration rather than a configuration detail.

The three redacted fields are the ones I would plan around. Nothing reads env, headers or CLIENT_SECRET back once they are saved, so keep those values wherever you already keep secrets; the next rotation will need them.

A server that authenticates over OAuth still needs every person to authorize it individually, even when it is shared at team level. Onboarding a teammate onto one of those takes one step more than adding them to the team.

That is also the thing to rule out first when a server works in your runs and not in a colleague's.

Cloud agents automatically try to fix CI failures in pull requests they create. This currently supports GitHub Actions only, and automatic fixing is available on Teams today, with support for non-Teams accounts described as coming soon.

Accounts outside Teams are not shut out of the behavior, exactly. Cursor's suggestion in the meantime is to ask the cloud agent explicitly to monitor and fix CI failures on the PR.

Four conditions stop the automatic follow-up. An agent skips an auto-fix in any of the cases below, and between them they keep it off your own commits and cap how many times it can retry.

• You pushed a new commit to the branch; agents do not auto-fix CI failures on human commits.
• You sent a follow-up message to the agent.
• The same check is already failing on the base commit of the PR.
• The PR has already had 10 CI-failure follow-ups.

When nothing happened at all, the base-commit condition is worth checking before the others. A check that already fails on the base commit means the branch you forked from brought the failure with it, so the base branch is where the fix belongs. The commit rule catches people the other way round, since your own push stops the automatic follow-up too.

Hitting the ten-follow-up ceiling is itself information. The count is per PR, not per check, so ten agent attempts at the CI on one branch is a decent signal that an eleventh will not clear it. Read the run yourself at that point instead of hunting for a way to raise the cap. A flaky integration test will happily consume the whole allowance and leave the branch where it started.

Since August 19, 2026 this behaviour has a name. Cursor's changelog describes cloud agents as automatically subscribing to the PRs they create and driving them to completion, fixing CI and addressing bot comments, which is the same loop with a wider remit: bot review comments count now, not only red checks. The harness release section below covers what else a subscription can watch.

You can disable this on all your personal cloud agents under Cursor Dashboard → Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. → My Settings by turning off Automatically fix CI Failures. To control it per PR, comment @cursor autofix off to disable it and @cursor autofix on to re-enable it. You can also ask an agent to fix CI directly by tagging it in a comment, for example @cursor please fix the CI failures.

On August 19, 2026 Cursor shipped a changelog entry titled "Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. and Cursor Harness Improvements," and the framing is worth quoting because it tells you what the five features are for: always-on agents that can "operate as a system, building and shipping software on their own without the need for intervention at each loop." Three of the five are about not stopping. Two are about not drifting.

The subscription row is the one that changes how you plan work, and it pays to be precise about what subscribes to what. Cloud agents automatically subscribe to the PRs they create; that part needs no setup. Watching a Slack thread is something you ask for, with a prompt like the one in the caption. Scheduled tasks existed already as Automations; what is new is that the same wake-on-event idea now covers a thread or a PR as well as a clock. I would treat the "for now" in "cloud agents only, for now" as a real qualifier rather than filler, since the release notes are careful elsewhere about what is and is not in scope.

Subagents on separate VMs solve a collision problem the single-VM model had. Two subagents editing the same checkout could step on each other's files; each now gets its own copy of the project, so the changelog's suggested use, a swarm of subagents testing an app for bugs each in its own environment, is safe in a way it was not before. The price is the one you would expect: each VM is a fresh clone with clean context, so anything a subagent needs to know has to travel in the prompt.

Steering looks minor next to the rest and is probably the one you will use most. Before this release a follow-up interrupted the agent; now it queues until the next tool call, which means you can correct course mid-run without losing the half-finished action. The two-Return shortcut matters for the same reason: it makes the queued message the default, and the interrupting one the deliberate choice.

Yes, without a stored credential. Cursor's cloud-agent identity docs describe an API, local to the agent VM, from which an agent can mint a short-lived OIDCOpenID Connect. The modern single sign-on standard, built as an identity layer on top of OAuth 2.0. Where SAML is XML and enterprise-legacy, OIDC is JSON and what newer tools implement first. Press Enter for the full definition. JWT and present it to AWS STS, GCP, Azure, Vault, or a service you run. The verifier checks the signature against Cursor's published JWKS and authorizes on claims such as the subject, team id or cloud agent id. The point is in the docs' own framing: assume a cloud role or call an internal service without keeping a long-lived secret in the agent's Secrets store.

The same socket serves a second, smaller API that is easy to confuse with the first. Agent metadata, which Cursor marks as a preview subject to breaking changes, lets the agent, its hooks and its install scripts read key-value facts about the current run: the agent id, who owns it, who submitted this turn, which model is serving, and which repos are checked out. Keys live under four prefixes, agent/, owner/, turn/ and workspace/, and a key exists only when it has a value, so turn/ disappears between coding turns. Self-hosted workers do not serve this API yet.

Where this lands in practice is the install script. Both docs say install scripts can use the socket, so a script can ask owner/team-id to decide which configuration to load, then mint a token to pull a private dependency, and the agent starts its coding turn already authorized. The retry note is easy to miss and worth keeping: if the socket is missing right after boot, retry the connection rather than failing the build.