Cursor Cloud Agents: Capabilities

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.

Agents create artifacts such as screenshots, videos, and log references to demonstrate what they did, and those artifacts attach to the pull request. The point is that 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. dashboard to turn this on.

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.

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. (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. 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.

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.

The automatic follow-up is deliberately conservative. An agent skips an auto-fix in any of the cases below, so it does not act on top of your changes or loop indefinitely.

• 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.

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. → 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.