Guide
Cursor Cloud Agents Guide
Cursor's June 2026 Cloud Agents update added guided cloud environment setup, reusable snapshots, .cursor/environment.json, /in-cloud subagents, /babysit for PR supervision and more reliable local/cloud handoff.
On this page
- What changed in Cursor Cloud Agents, June 2026?
- How should a team use Cursor Cloud Agents?
- What should stay bounded?
- How do artifacts, grind mode and self-hosting work?
- How does self-hosted Cloud Run fit?
- How do I think about and orchestrate a cloud agent?
- Can I drive a cloud agent from Slack?
- What does a cloud agent hand back besides a diff?
What changed in Cursor Cloud Agents, June 2026?
Cursor's June 2026 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. update added guided cloud environment setup, reusable snapshots, .cursor/environment.json, /in-cloud subagents, /babysit for PR supervision and more reliable local/cloud handoff.
- Release fact
- Cloud setup
- Why it matters
- Cursor can help set up a cloud development environment in less than 10 minutes.
- Release fact
- Reusable snapshots
- Why it matters
- Working environments can be captured so future cloud agents boot faster and can run software.
- Release fact
- /in-cloud
- Why it matters
- A cloud subagent runs the next task in its own VM and branch.
- Release fact
- /babysit
- Why it matters
- A cloud agent can keep iterating on a PR until it is closer to merge-ready.
- Release fact
- Handoff
- Why it matters
- Work can move from local to cloud and back while preserving branch and verification context.
| Release fact | Why it matters |
|---|---|
| Cloud setup | Cursor can help set up a cloud development environment in less than 10 minutes. |
| Reusable snapshots | Working environments can be captured so future cloud agents boot faster and can run software. |
| /in-cloud | A cloud subagent runs the next task in its own VM and branch. |
| /babysit | A cloud agent can keep iterating on a PR until it is closer to merge-ready. |
| Handoff | Work can move from local to cloud and back while preserving branch and verification context. |
As of July 9, 2026. See the linked Cursor sources for the latest details.
This exact topic is a hands-on lesson: Cloud Agent Basics — about 5 minutes, free to read.
How should a team use Cursor Cloud Agents?
Knowing what shipped is the easy part. Turning Cursor 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. into something a team relies on takes a few deliberate steps, mapped below.
- 1Use local Agent or Plan Mode for ambiguous work that needs close supervision.
- 2Set up a cloud environment with install, start and verification commands before delegating long work.
- 3Launch
/in-cloudonly for tasks with separate branch boundaries and low conflict risk. - 4Pull the result back locally and rerun the checks a human reviewer would trust.
What should stay bounded?
New capability comes with new ways to get it wrong. Keep these boundaries in place as you adopt it.
Do not send work to cloud until the environment can actually install, start and test the repo.
Use separate branches for parallel agents and review one output at a time.
Keep sensitive or high-blast-radius work local unless the data-flow and secret boundary are approved.
How do artifacts, grind mode and self-hosting work?
A cloud agent runs in an isolated, Cursor-managed VM with its own desktop and terminal. It checks out the repo, does the work, opens a PR, then the VM is torn down. It uses no local RAM or disk, so you can run as many as you want while your laptop is closed.
Artifacts: proof of work
Because the agent can drive its own virtual desktop, it can verify work the way a person would: make a change, spin up a browser, test it, record a video and screenshots, and self-correct on console errors. On completion it returns that walk-through video plus screenshots, type-checks and test results, and can upload the video straight to the PR.
If a task's output is artifact-verifiable, route it async to a cloud agent - the artifact is how you trust the result.
If the work is fuzzier and needs your judgment along the way, stay foreground and local.
Grind mode
Grind until done is a toggle that lets a cloud agent work autonomously for hours, or as long as needed, on the longest jobs - big migrations or building something from scratch. Most tasks don't need it; just turning cloud on and asking for the feature already does well. Reserve grind mode for the toughest work.
A self-hosted (private worker) cloud agent runs the VM inside your network so it can reach on-prem source control and internal 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.
Inference still calls external model providers - exactly like the desktop app calling a provider API. "Self-hosted" is about where the container runs, not where the model runs.
Multi-repo per single cloud agent is largely not supported yet; an agent is tied one-to-one to a PR.
How does self-hosted Cloud Run fit?
Cursor's Cloud Run worker-pool guide is a reference setup for Self-Hosted 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. on Google Cloud. It is not a second product surface; it is a deployment pattern for teams that need the worker containers and build artifacts in their own cloud environment while still connecting back to Cursor's fleet management API.
- Piece
- Cursor worker pool
- What Cursor documents
- A Cloud Run Worker Pool runs containers that start the
agentCLI as pool workers and hold outbound HTTPS connections to Cursor.
- Piece
- Autoscaler pool
- What Cursor documents
- A second single-instance Worker Pool polls Cursor's private-workers summary API and resizes the worker pool through the Cloud Run Admin API.
- Piece
- Prerequisites
- What Cursor documents
- Google Cloud billing,
gcloud, Cloud Run, Artifact Registry, Cloud Build, Secret Manager, a Cursor team plan with Self-Hosted 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. enabled and a team-level API key.
| Piece | What Cursor documents |
|---|---|
| Cursor worker pool | A Cloud Run Worker Pool runs containers that start the agent CLI as pool workers and hold outbound HTTPS connections to Cursor. |
| Autoscaler pool | A second single-instance Worker Pool polls Cursor's private-workers summary API and resizes the worker pool through the Cloud Run Admin API. |
| Prerequisites | Google Cloud billing, gcloud, Cloud Run, Artifact Registry, Cloud Build, Secret Manager, a Cursor team plan with Self-Hosted 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. enabled and a team-level API key. |
Use the Cloud Run doc as a minimal reference setup, then adapt images, secrets and autoscaling to your infrastructure.
How do I think about and orchestrate a cloud agent?
The mental model that makes cloud agents click: a cloud agent is an engineer with a laptop in the cloud. Cursor's surfaces - Slack, Linear, the IDE - are just different ways to orchestrate that cloud developer. You hand off a task into the background and go do something else. For non-developer roles this is one of the highest-value things to set up early.
Once you stop thinking of a cloud run as a job and start thinking of it as a teammate you brief and check back on, the orchestration surfaces make sense.
think about it like as an engineer with a laptop in the cloud is like what a cloud agent is.
The launch flow itself is device-independent. Go to cursor.com/agents from anything - one presenter kicked off a run from a phone on the Bay Bridge. Pick a repository and branch, give a command, choose a model, optionally link 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 (Slack, for example), and start it. The run spins up a brand-new VM that mirrors your GitHub repo, your in-repo rules and system prompts, your MCP servers and your skills, so repo-specific slash commandsSaved multi-step prompts you trigger from the / menu, such as run tests, fix CI or open a pull request. Press Enter for the full definition. still work inside the cloud run.
Skills and slash commandsSaved multi-step prompts you trigger from the / menu, such as run tests, fix CI or open a pull request. Press Enter for the full definition. defined in the repo are available in the cloud run, not just locally.
This spins up a brand new VM that has all your information of what your GitHub repository looks like... and it has skill integrated as well. You can actually do slash commandsSaved multi-step prompts you trigger from the / menu, such as run tests, fix CI or open a pull request. Press Enter for the full definition. with that skill.
- You can run roughly 3-5 concurrently, each on its own branch.
- A typical run takes about 10-15 minutes minimum end to end.
- Link an 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. server (e.g. Slack) at launch so the run can reach the tools the task needs.
Can I drive a cloud agent from Slack?
Yes - the Slack integration (one of Cursor's first) lets you invoke a cloud agent from where conversations already happen, with a human in the loop the whole way. The flow is async and in the flow of work: ask a question in a thread, Cursor launches a cloud agent that answers, then you tell it to implement and it spins up a VM and takes a shot. The Slack conversation copies over to cursor.com where you can follow the diff line by line.
A PM hit a missing-docs gap for an AWS Bedrock integration, dropped it into Slack, and Cursor read the code and drafted the docs. An engineer replied in-thread flagging two things that were wrong; the PM told Cursor over the same thread to fix them; then it shipped. The whole loop was human-reviewed and finished inside the thread.
We had Cursor go in through the Slack thread, update the docs, and then it was shipped. And that... happened within 15 minutes all over Slack.
Webhook-triggered, unattended runs
You can go further and trigger a cloud agent with no human at the keyboard. One growth engineer wired a webhook on every inbound to enterprise@: it fires a cloud agent that drafts a tailored reply grounded in docs plus the user table, so it knows whether the sender is an existing customer expanding or a net-new demo request. Data sources wired in were Databricks for user data, Slack for release chatter and Notion for internal docs. Front handled the inbox and a Zap passed the conversation ID to trigger the agent.
An unattended pipeline needs the credential to be present without a person pasting it. The pattern is to inject the API key into the cloud agent so it runs on its own.
I have this web hook running that's always listening to any calls to enterprise at... I have the API key automatically injected into the cloud agent, so it's able to run this automatically.
What does a cloud agent hand back besides a diff?
More than a PR. A cloud run returns Artifacts - screenshots and screen recordings of what it built - so you can judge behavior without running anything yourself. In one demo an Opus cloud run was told to build a bot, use a repo skill, and "give me a demo"; it handed back a video of the bot fighting and winning. You watch the recording, like it, open the PR, merge.
The recording is your evidence. If a task's output is something you can watch and verify, route it async and let the artifact be how you trust it.
It not only provides you a diff file of the PR that it created, it also gives you (internally we call it artifacts) screenshots as well as screen recordings.
Cursor is exploring running iOS and Android simulators inside cloud agents to make mobile testing more fluid than today's cross-app 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. bridge.
Because Android is Linux-based, someone on the team already got a cloud agent to run an Android simulator - but only with a lot of hand-holding instructions. A more integrated, no-instructions experience is not rolled out yet and has no date. Treat it as roadmap.
Frequently asked questions
Who is this guide for?
Developers and platform teams deciding when work should run locally, in a cloud agent or in parallel cloud subagents.
What should I do next?
Start with one real repo task, capture the prompt and review the result before scaling the workflow.
Is a self-hosted cloud agent self-hosted inference?
No. A self-hosted (private worker) cloud agent runs the container in your network so it can access on-prem repos and internal tools, but the model inference still calls out to external providers, just like the desktop app. It is for assets that can't touch the internet and strict compliance needs, not fully on-prem AI.
How many cloud agents can I run at once and how long do they take?
You can run roughly 3-5 cloud agents concurrently, each working on its own branch. A typical run takes about 10-15 minutes minimum end to end, which is why the right work to delegate is something you can hand off and check back on rather than watch live.
Can I trigger a cloud agent automatically, without a person prompting it?
Yes. You can wire a webhook to fire a cloud agent on an inbound event (for example every email to an enterprise inbox), with the API key injected into the agent so it runs unattended. The agent can draft a context-rich result grounded in your docs and data sources, then a human reviews before anything ships.
Sources & last verified
- Cursor changelog: Cloud Environment Setup and Cloud Subagents
- Cursor blog: Development environments for your cloud agents
- Cursor docs: Self-Hosted Cloud Run Worker Pools
- Cursor enterprise
Cursor ships frequently. Facts verified against primary sources on July 9, 2026.
Keep reading
Rather do it than read about it? Run 11 interactive Cursor walkthroughs in a simulated editor. Free, no account needed.