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.