What Cursor Cloud Agents Can Do: Capabilities and Limits

Each cloud agent runs in its own isolated VM with a full desktop environment. 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 check that a change works before it pushes a pull request.

The bigger difference from the agent in your editor is approval. On your machine, Run Modes decide which tool calls wait for you. Cursor's Run Modes page says cloud agents don't use Run Modes: each one runs inside its own dedicated machine, so it never asks you to approve an action. It can keep retrying a failing test while you do something else.

Cursor's Secrets & Network page names that auto-run behavior as a data exfiltration risk, because a prompt injection meets no approval step. The same page still says the foreground agent requires approval for every command, which the Run Modes page contradicts: locally, allowlisted actions run without approval, and Run Everything runs every tool call automatically. Our security and network guide covers what to do about the risk.

Check whether your repo qualifies before you plan a workflow around this. Computer use is supported for repos with Dockerfiles based on Debian or Ubuntu, and other distributions need a support request. The rule is about the base image your Dockerfile starts from. A repo with no Dockerfile runs on Cursor's default Ubuntu machine. The team switch for computer use is 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, for enterprise teams only.

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

You can also opt in to embed artifacts directly in GitHub pull request descriptions. To turn this on, 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.

Whether unguessable is protection enough depends on what the artifacts show. A recording of an internal admin flow carries more risk than a screenshot of a marketing page, and the setting covers every artifact that follows.

Your reviewers decide which way to set it. If the PR goes to two or three people who all work in Cursor, they open the agent anyway, so the attached artifacts are enough and public URLs add nothing. Once review includes people who never open Cursor, a recording has to sit in the description to get watched, and the public URLs are the price of that.

If artifacts stop showing up on your PRs, check egress first. On Cursor-hosted agents, uploads go to a dedicated host, and blocking it stops the uploads while the rest of the run keeps working. Our security and network guide names the host to allowlist.

Yes. You can take control of the agent's remote desktop to use the software it is building, then hand control back at any time so the agent keeps working.

The remote VM can be fully onboarded with your repo, dependencies, tooling and setup scripts. Once it is, you can test changes in the agent's VM instead of checking out the branch on your own machine.

A cloud agent runs on a default VM profile with limited memory and CPU. On an Enterprise plan, support can raise those limits for your workspace, and Cursor lists self-serve resource configuration as coming soon. The takeover suits a flaky UI flow you want to watch yourself. It is a poor fit for the heavy build you were avoiding on your laptop.

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 external tools and data sources such as databases, APIs and third-party services during a run. You add personal servers through the MCP dropdown at cursor.com/agents, and team admins configure shared servers under Dashboard → Plugins & MCPs. OAuth works for servers that need it, and it is per user, even for servers shared at the team level.

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 can use 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, so no user can read them back.

Cursor recommends HTTP over stdio. For most teams, the deciding factor is where each transport runs and which credentials the agent's VM can reach.

The stdio caveat in that caption costs the most time. A missing binary or a wrong path in a stdio server shows up only once a run is under way, and each fix means launching another agent to check. HTTP servers don't depend on the VM that way.

Our desktop 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. guide describes a remote server as a URL over streamable HTTP or SSE. Cloud agents take only the HTTP half, so a vendor whose only remote endpoint is SSE is blocked, whatever you configure.

Plan around the redacted fields: keep env, headers and CLIENT_SECRET values in the secrets store you already use, because the next rotation will need them. An OAuth server also needs each person to authorize it, even when it is shared with the team. When a server works in your runs but not in a colleague's, rule that out first.

Cloud agents automatically try to fix CI failures in pull requests they create. This currently works with GitHub Actions only, on Teams and Enterprise plans. On other plans, Cursor suggests asking the cloud agent to monitor and fix CI failures on the PR.

Four conditions stop the automatic follow-up. Between them, they keep it off your own commits and cap how many times it retries.

• 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, check the base-commit condition first. A check that already fails on the base commit came with the branch you forked from, so the fix belongs on the base branch. The commit rule catches people the other way round: your own push stops the automatic follow-up too.

Reaching ten follow-ups is a signal in itself. The count is per PR, not per check, so ten agent attempts on one branch suggest an eleventh won't clear it either. Read the run yourself instead of looking for a way to raise the cap, since a flaky integration test can use up the whole allowance.

To turn this off for all your personal cloud agents, go to 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 and disable Automatically fix CI Failures. On one PR, comment @cursor autofix off to stop it and @cursor autofix on to resume it. You can also ask for a fix directly in a comment, for example @cursor please fix the CI failures.

Cursor's August 19, 2026 changelog widened this loop: cloud agents subscribe to the PRs they create and drive them to completion, fixing CI and addressing bot comments. The harness release section covers what else a subscription can watch.

Cursor's August 19, 2026 changelog, "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," added five features 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." It says that with this release, cloud agents can "automatically pick up work in response to events, hold a goal until it's met, and stay on course through long-running sessions."

Be precise about what subscribes to what. Cursor's capabilities docs say you start a subscription by describing the wait in your prompt, such as "open a PR and keep CI green," or by invoking the built-in /subscribe skill. The changelog adds that cloud agents subscribe to PRs they create. Events arrive as follow-ups in the same conversation, and a burst of events can wake the agent once.

A subscription lasts at most 180 days and needs an agent that a person owns. For a standing rule that fires on a schedule or an event, use an automation instead.

Subagents on their own machines can work side by side "without collisions," in the changelog's words, because each one gets an isolated copy of the project. The price is context. Each VM starts clean, so anything a subagent needs to know has to travel in its prompt.

Steering changes a routine action: sending a correction while the agent works. The correction now lands at the next tool call, so you can change course without losing a half-finished action.

Yes, without a stored credential. An API local to the agent's VM lets the agent 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 agent can then assume a cloud role or call an internal service without a long-lived secret in its 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 facts about the current run. Those facts include the agent id, its owner, who submitted this turn, which model is serving and which repos are checked out. Keys sit under four prefixes, agent/, owner/, turn/ and workspace/, and a key exists only while it has a value, so turn/ disappears between coding turns. Self-hosted workers don't serve metadata yet.

Both docs say install scripts can use the socket. Install scripts now run during Builds, ahead of agent runs, and a token lasts 5 minutes with no refresh, so mint a token in the step that uses it. If the socket is missing right after boot, retry the connection instead of failing the script.