Cursor Cloud Agents May 2026: 2 gaps it still can't close

On May 13, Cursor shipped multi-repo cloud agent environments. Cursor's own product page says more than 30% of the pull requests it merges are now created by autonomous agents operating in cloud sandboxes.

What Cursor actually shipped on May 13

The headline feature is multi-repo cloud agent environments. Agents can now operate across multiple repositories inside a single configured environment, building on the multi-root workspaces Cursor shipped on April 24. The environment is reusable across sessions, which is the practical part – you stop reconfiguring the same dev box every time an agent kicks off.

The configuration surface is a Dockerfile. Build secrets are scoped to the build step and are not passed to the running agent, which closes the most common foot-gun in agent infra: an API key baked into a build accidentally ending up in an agent's working memory. Cursor can also configure the Dockerfile by inspecting your repos for tools and dependencies. That flow remains in private beta for Enterprise teams.

Layer caching got the biggest performance bump. Cache-hit builds now run 70% faster because only the changed Dockerfile layers rebuild. For agents that spin up repeatedly across a team, that's the difference between waiting and working.

The operational surface is the part competitors keep underselling. Every environment has a version history with rollback. Rollback is admin-restricted. An audit log captures every action team members take on environments. Egress allowlists and secret scopes are per-environment, so a secret available to environment A is not reachable from environment B. This is the boring infrastructure you need before you let an agent open PRs against production code.

The proof point Cursor put in the announcement is Amplitude. Their Cursor Automations watch public Slack channels, investigate reported issues, figure out which repos are affected, and open PRs across the right repos. That's a multi-repo agent doing first-line triage at a real company at real scale. It is not a demo.

Cursor's own merged-PR number is the proof point

Cursor says more than 30% of the pull requests it merges are now created by autonomous agents operating in cloud sandboxes. The denominator matters: these are merged pull requests, not agent attempts. That is the proof point that tells you the loop can close through review, fixes, and handoff without a human pushing every commit.

Since September 2, 2026, Cursor's Self-Hosted Machines lets teams move file edits, terminal commands, computer-use tools, and local MCP execution onto customer-managed workers while Cursor keeps the agent loop, inference, and planning in its cloud. That closes the private execution-location gap, but it does not turn Cursor into a programmable durable runtime.

The choice is no longer session-scoped versus durable. Cursor persists conversation state in its backend so runs can be revisited and resumed, and Self-Hosted Team Pools can restore a hibernated workspace. The sharper distinction is vendor-managed agent state versus programmable application state. Cloudflare exposes per-Agent SQLite state and durable workflow steps that you control in code.

What my Cloudflare Workers and Agents SDK stack already does

I run six production agents on Cloudflare. The runtime is Workers; state lives in Durable Objects with per-instance SQLite; long-running orchestration runs on Cloudflare Workflows. Solo build, single account, decoded in detail here. The full Cloudflare stack cost $19.14 in April 2026. That is a dated production bill, not a platform quote. Cursor lists Enterprise as Custom; Team Pools require Enterprise, and Self-Hosted Machines still incur selected-model charges plus your worker bill.

Three ways this stack differs from Cursor's current product.

Multi-repo, by code. A Worker can fetch resources over HTTP at runtime. Browser Run, formerly Browser Rendering, can control a headless browser when context sits behind a website. Cursor packages multi-repo access as reusable environment configuration; Cloudflare leaves the fetch, authentication, and repository logic to you. Not better, not worse, just a different control surface.

Programmable durable state. A Cloudflare Agent automatically saves application state to its own SQLite database and reloads it after a restart or hibernation. Cursor also preserves conversation state and supports resuming runs. The difference is control: Cursor owns the conversation store and agent runtime, while Cloudflare exposes application state and its schema to your code.

Durable step boundaries, not automatic exactly-once execution. In Workflows, each step is individually retryable and may emit state so execution can persist and continue after a network or infrastructure failure. step.do accepts per-step retry configuration, NonRetryableError stops retries for terminal failures, and instance IDs are unique per Workflow. But a step may run more than once, and Cloudflare explicitly tells you to make side-effecting calls idempotent. The advantage is developer-defined durability and retry control, not automatic protection from duplicate pull requests, emails, or charges.

The two gaps Cursor still has not closed

Gap 1: customer-controlled programmable agent state. Cursor has solved basic resumability: conversation state is retained indefinitely by default, and managed VM snapshots follow a rolling 90-day inactivity window. Self-Hosted Machines moves tool execution, but Cursor still operates the agent loop and stores the conversation. A Cloudflare Agent exposes SQLite-backed state inside the application runtime. This matters when an agent monitors incidents, coordinates a migration, or carries business state across a multi-day onboarding flow.

That is narrower than the gap described in May. Cursor can resume its product's agent runs. It does not expose a customer-owned state machine that your application can query, extend, and coordinate independently of a Cursor chat.

Gap 2: a developer-defined durable step surface. Cursor's current Cloud Agent and Self-Hosted Machine documentation exposes no application primitive equivalent to a Workflow step with persisted state and per-step retry configuration. Cloudflare does. That difference matters when a coding agent crosses into billing, email, deployment, or another external side effect.

Moving tool calls onto your own machine does not close that gap because it changes execution location, not the orchestration contract. Cloudflare does not make side effects exactly-once either; you still have to make a retrying step idempotent.

None of this is a knock on Cursor. It's a statement about category. Cursor is a coding product with both managed and customer-operated tool execution. Cloudflare is a programmable application runtime. The September release narrows the infrastructure gap, but the state and orchestration boundary still separates them.

What founders and CTOs should do this week

Three profiles, three different moves.

If you're a small product team shipping product features, use Cursor-managed Cloud Agents when its environments and network controls can reproduce your build. The May 13 environment release handles multi-repo setup, build secrets, caching, and auditability, while Cursor's more-than-30% merged-PR disclosure is the public proof point. Don't operate a worker fleet without a policy reason.

If you're already on Cloudflare or Vercel running long-lived background processes, keep durable application state and orchestration there. Cursor Self-Hosted Machines can now use Cloudflare or Vercel infrastructure for tool execution, but Cursor still owns the agent loop. There's a consumer-side parallel worth reading for how Anthropic is packaging similar primitives for SMBs – the pattern of platforms converging on agents is showing up everywhere.

If you're planning an enterprise rollout, start with managed Cloud Agents when allowlists, Tailscale, AWS PrivateLink, or Cloudflare Tunnel meet the access requirement. Use Team Pools when the checkout, tool execution, custom hardware, or worker image must stay under your control. Team Pools require Enterprise, whose price is Custom, and Cursor-configured Dockerfiles remain in private beta.

What changed after May

Two signals.

First, Cursor now documents conversation state separately from the runtime workspace. Conversation state is kept indefinitely by default so you can revisit and resume runs; managed VM snapshots expire after 90 days of inactivity unless a start or resume extends the window. Basic resumability is no longer a gap. Ownership and programmability are.

Second, private execution location is no longer a gap. Self-Hosted Machines addresses it while leaving the agent loop, inference, and planning in Cursor's cloud. Customer-controlled agent state and a developer-defined durable step surface remain the two meaningful differences.

Does Cursor's May 13 release deprecate the need for self-hosted agent infrastructure?

No. Cursor now offers its own self-hosted path: My Machines for personal workflows and Team Pools for Enterprise fleets. That moves tool execution into your network, but Cursor still runs the agent loop and stores conversation state. Teams that need a programmable application runtime or durable workflow steps still need infrastructure for those layers.

How fast are Cursor's cached cloud agent builds now?

Cache-hit builds run 70% faster after the May 13 layer caching upgrade. Only the changed Dockerfile layers rebuild on a cache hit.

What does Cursor's internal merged-PR number mean?

Cursor's current first-party page says more than 30% of the pull requests it merges are created by autonomous agents operating in cloud sandboxes. It is a useful production-adoption proof point because it measures merged pull requests, not attempted tasks.

Are Cursor cloud agents safe for code that touches production secrets?

The May 13 release scopes egress and secrets per environment, isolates build secrets from the running agent, and exposes version history, rollback, and audit logs. Self-Hosted Machines can keep the full checkout and machine-local credentials on your worker, but needed file contents, tool output, diffs, screenshots, and local MCP results can still go to Cursor. Safety depends on approving both boundaries.

Can I run Cloudflare Workers and Cursor cloud agents side by side?

Yes. Cursor lists Cloudflare as a Self-Hosted Machines integration, and its reference template uses a Cloudflare Worker as a controller to start one Cloudflare Container per claimed request. Cursor can handle the coding-agent loop while Workers, Durable Objects, and Workflows handle durable application state and orchestration. The products now overlap at tool execution, but not at the agent-loop boundary.