Unable to start Cloud Agents with a configured Environment

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

Any time myself or anyone on my team attempts to start a cloud agent with a configured environment, it crashes with a generic error before streaming any messages or giving me any kind of indication of why:

Agent encountered an error
We encountered an unexpected error repeatedly.
You can retry by writing a follow-up below.

This is a new problem (creeped in over the last couple weeks) - my team has been successfully using cloud agents for months. While poking around and attempting to figure out the issue, I was able to divine that completely removing the configured environment for my repository would allow the environments to boot back up again.

As soon as I add it back as a Team environment, the failures return. Switching it to a Personal environment makes it work again for me, but my entire team remains blocked.

Debugging details:

I see this console error the moment the chat thread crashes:

[BackgroundComposer] Failed to stream environment logs bc-5d9905f5-2978-49c4-87cf-afc8deef247f Error: Failed to attach environment logs (504): <!DOCTYPE html><html><head><meta charSet="utf-8" data-next-head=""/><meta name="viewport" content="width=device-width" data-next-head=""/><title data-next-head="">500: Internal Server Error</title><noscript data-n-css=""></noscript><script defer="" noModule="" src="/_next/static/chunks/polyfills-42372ed130431b0a.js?dpl=dpl_8KnRWV2KGKYDaumwqfnzwVQBjBR6"></script><script src="/_next/static/chunks/webpack-154f0641592345f1.js?dpl=dpl_8KnRWV2KGKYDaumwqfnzwVQBjBR6" defer=""></script><script src="/_next/static/chunks/framework-8082588acbf4dc4f.js?dpl=dpl_8KnRWV2KGKYDaumwqfnzwVQBjBR6" defer=""></script><script src="/_next/static/...[truncated]

Also, seeing lots of errors in console from 400 POST https://cursor.com/api/background-composer/get-machine with the response body:

{"error":{"message":"Error","details":[{"error":"ERROR_BAD_REQUEST","details":{"title":"Bad Request","detail":"Machine info is not available","isRetryable":false,"additionalInfo":{},"buttons":[],"planChoices":[]},"isExpected":true}]}}

Steps to Reproduce

It is possible that our environment is too large/complex and tipping something over. We have roughly a dozen underlying docker images that spin up alongside the dev environment, and the project is a very sizeable monorepo with a dozen more parallel running services.

Expected Behavior

Cursor cloud agents should reliably start up and be able to launch desktop mode and our development environment server

Operating System

MacOS

Version Information

Latest (web)

For AI issues: which model did you use?

Same issue across all models

Does this stop you from using Cursor

Yes - Cursor is unusable

7

Hi Matt!
This is a confirmed bug on our side. Team environments with complex Dockerfile configurations are producing snapshots that can’t be restored, which is why every subsequent cloud agent run fails after the initial setup.

What your team can try now:

  1. Trivial Dockerfile change to force a fresh build - adding or modifying a comment in your Dockerfile or install script will invalidate the current snapshot and force a cold start (which should succeed). Note: this is a temporary workaround - the next snapshot will likely fail again on subsequent runs.

  2. Personal environments as interim - as you discovered, Personal environments work. Each team member could set up their own Personal environment with the same configuration until this is fixed.

Our engineering team is aware of this issue and it’s being tracked. I don’t have a specific timeline for a fix, but it’s on the Async Agents team’s radar.

8

To clarify, our environment uses both docker and immediate running hosts in tandem. Services like Postgres fire up in docker on the environment while the actual development server fires up as a live node process on the machine.

  1. I don’t know which dockerfile you’re talking about specifically, but modifying the startup/install script for the team environment on the cloud agents dashboard settings page had no observable effect and agents are still unable to start with it enabled. Can you please some more specifics about how the snapshots are triggered by subsequent runs and how I can leverage this workaround?
  2. I’ll advise my team in the meantime to set up personal environments to unblock themselves

I do hope this is high on the team’s radar - this is blocking many teams across my organization who were relying on cloud agents and automations to migrate and improve/refactor their systems regularly. Many of our code quality improvement initiatives are totally stalled while this is broken, not to mention engineer’s workflows when triggering cloud agent PR followups to bugbot feedback.

9

To answer your question about how snapshots work: when you first set up a Team environment, a snapshot of the fully built state is captured. Every subsequent cloud agent run restores from that snapshot rather than building from scratch. The issue is that the snapshot produced by complex Docker-based environments is getting corrupted during the capture or restore process, which is why every run after the initial setup fails.

One thing worth trying: go to your Cloud Agents dashboard → Environments tab → find the Team environment → delete it entirely, then set it up again. This should force a full cold start (which should succeed as the first run). The caveat: the next snapshot it creates may also fail on subsequent runs, so this would be a temporary fix rather than a permanent one.

If that’s not worth the effort, Personal environments remain the most reliable workaround until the underlying bug is fixed. I know it’s not ideal for a 47-seat team, but it bypasses the broken snapshot entirely.

This is being treated as a high-priority item by our engineering team. I’ve made sure the full scope of the impact - multiple teams blocked, automations stalled, PR followup workflows broken - is reflected in the tracking.

10

Thanks Mohit, much appreciated. After regenerating and restoring a team environment multiple times due to this seemingly random corruption, I’ve advised everyone to roll with personal environments for now.

11

Adding a second affected team. We’re hitting this exact bug. Multi-repo, Docker-based Team environment it works on the first cold start then dies on every run after with the same useless “Agent encountered an error”. We’ve spent the best part of three months trying to work around continued cloud agent errors and bugs and this is the latest thats adding more friction in using Cloud agents.

mohitjain, thanks for confirming it. But “everyone move to Personal environments” isn’t a workaround — the Team environment is the whole reason we’re on a paid Team plan. Telling us to each rebuild and maintain our own copy of a dozen-service Docker setup is asking us to stop using the feature we’re paying for and bring back exactly the per-dev drift Team environments are meant to kill. And the other suggestion (trivial Dockerfile change to force a rebuild) just resets until the next snapshot corrupts again, so there’s currently no stable way to run a Docker-based Team environment at all.

One thing that is most frustrating is there is no feedback as to what the problem is. If we had logs or a meaningful error that could help us mitigate or debug the problems ourselves it would be something. Just get an “Agent encountered error” message gives us nothing to work off.

We’re not trying to be difficult we use Cursor heavily and want it to work. But a confirmed bug in a core paid feature, hitting multiple teams, with no timeline, needs proper escalation rather than temporary mitigations.

Happy to share environment IDs and failing run links to help reproduce.

13

Hey everyone, a backend fix shipped on June 4. The root cause turned out to be a multi-repo environment setup bug (not the snapshot-corruption theory I floated earlier), which is also why the only “workarounds” were forced rebuilds that kept breaking. Since Cloud Agents run on the web, there’s nothing to update on your end - the fix is already live.

Could you give your Team environment another run and let me know if it starts cleanly now? Same ask for you, @mmmeff If either of you still hits a failure, drop an environment ID and a failing run link here and I’ll dig into it directly.

cc: @oh_moore

14

@mohitjain I cleared out all team/personal environments and kicked off a fresh environment agent. After it runs, I then attempt to save it, but my client is getting a 500 from the snapshot-and-save-environment API endpoint.

Response: {“error”:{“message”:“internal error”,“details”:}}

x-vercel-id sfo1::iad1::q2g5g-1780966906486-60aa0ead842c
15

Thanks for testing so fast, Matt - and sorry you’re hitting another error right after the last fix.

This save error is a separate, known issue from the multi-repo failure we fixed on June 4, and it’s not your environment config. It traces back to duplicate environment entries that can pile up when an environment is recreated repeatedly (which you mentioned doing to work around the original bug).

Since it’s a distinct issue from this thread’s original bug, could you open a new thread for it so we can track your specific case cleanly? Helpful to include:

  • That it happens when saving a Team environment after a fresh setup run

  • The exact error: {"error":{"message":"internal error","details":[]}}

  • The x-vercel-id from the failed save (you already grabbed one)

16

I will not @mohitjain - the bug report is the same - I am still unable to start environments.

As a customer, I do not care what the root causes are on your end, I would just like to see this resolved.

If there are more debugging steps I can do, please let me know.

17

is the problem that the environment cannot start due to its size/complexity? Is this just a timeout config somewhere y’all can tweak?

I’m seeing the get-machine API call fail with Cloud Agent machine is not ready yet. (cursorServerUrlReason=NO_VM_CONNECTION_INFO_YET

19

It isn’t your environment’s size or complexity, and it isn’t a timeout we can raise. NO_VM_CONNECTION_INFO_YET just means the machine for your run never finished starting, so there’s no connection info to hand back yet. In your case the restore of your saved Team environment is failing right at the start, before the machine comes up, so a longer timeout wouldn’t change anything.

This is a known issue on our side, not your configuration. When a Team environment launches from its saved snapshot, resolving repository access for that snapshot can fail immediately and abort the launch. Because the problematic reference is baked into the saved environment, re-saving or recreating the Team environment won’t clear it. Our engineering team has a fix in progress for exactly this.

Until that ships, a Personal environment (or running with no configured environment) should launch normally, the same as before. I’ll follow up here once the fix lands so you can re-test the Team environment.

20

Hello,

I have the same issue trying to save a personal environment with multi repo.

x-vercel-id: cdg1::mmkrp-1782140395750-7817280985d4

Can you have a look ?

21

Hey,

I’m also experiencing the same issue when creating a team and personal environment.

Vercel ID: lhr1::l5srq-1782198011607-130c656dadf1