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.

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.