Cloud Agent Environment Choosing

Support Help
, ,
1

I am building an cloud interface for Cursor tasks. I have the system using the SDK to create a Cursor Cloud instance. It loads 5 repos.

I am experiencing an issue where sometimes the cloud instance spins up and finishes in about 5-6 min, but sometimes with the same type of work, it takes 30-120 min for the same type of UI changes.

From the Cursor.com → Cloud Agents area, it shows I have multiple environments. When we create an environment in the interface, it loads each repo separately and cleans the .cursor/docker and environment.json if there is one. Cursor says when you load multiple environments, one must be he primary and the rest are listed as additional repos in the repos[] parameter. The primary should have the .cursor/docker and environments.json and only 1 environment should have this setup.. if more than 1 have it , then it will break the cloud instance when spinning up.

So, after the setup it will show 6 total “Environments” in the Cursor dashboard. There is no way to delete an environment from the SDK (only the Dashboard). Cursor shows that there is param to load by the Environment name, but that doesn’t seem to work. We have tries multiple iterations of names, even using the ones listed on the dashboard.

We believe the instances that take 30 to 120 min to run are when it loads 5 repos using an environment that only has 1 listed. There is 1 environment that includes all 5 repos, but using the SDK Cursor has not been able to match up how to load it by name.. the Environment names do not load, and when getting the environment list the name of each repo is blank.

If anyone has any input on this topic, please let me know. It’s hard to troubleshoot when spinning up a Cursor cloud instance takes 30-120 min.

5

Hey, thanks for the detailed report. I checked the environments on your account and I can explain both parts.

Environment selection by name. The API matches an environment by its saved name, with an exact match. Right now none of your environments has a saved name. The ones created automatically via repos[] are unnamed. The labels you see in the dashboard, like the repo name or repo +4 for multi-repo, are just display fallbacks, not saved names. That’s why nothing you tried matched.

How to fix it:

  • Open your 5-repo environment in the dashboard, then use ⋯ > Rename to set a name.
  • Run with env: { "type": "cloud", "name": "<that name>" } and completely remove repos. You can’t combine them, and a named environment already includes all 5 repos.
  • Or you can keep passing all 5 repos in repos[]. That will reuse the same environment instead of creating new ones.

Slow runs. This isn’t spin-up time. Spin-up is consistently fast. The variation is in how long the agent itself runs. The main reason is that your 5-repo environment has an empty setup config. It was created before .cursor/environment.json existed on the default branch of the main repo. It keeps getting reused as-is on every run, so the agent reinstalls dependencies from scratch every time. Open that environment in the dashboard and attach its config to .cursor/environment.json from the main repo. Or delete the environment and let the next multi-repo run recreate it. Now that the file is on the default branch, it will be picked up automatically. Your fastest runs were exactly the ones that used the prebuilt snapshot from that file. One more thing: the longest runs are the ones where the agent delegated work to multiple cloud subagents one after another, so a narrower request also helps.

Deleting environments. You’re right. Right now this is only possible in the dashboard, there’s no SDK endpoint. I passed this along as a request.

Try this and let me know how it goes.

7

I will try these changes.

The issue is that I already have an environment created with the 5 repos and it doesn’t have a name. So if I pass the 5 repos it will use the existing environment without the setup (because it cached to a time where it didn’t have that yet). If I were able to remotely delete that environment, create a new environment or force the environment to refresh with the newest checkin of those repos, I could fix this issue. Currently it seems the only way to get my environment to load with the .cursor/ setup would be to delete it from the Cursor web interface manually and then the next setup would create that environment from scratch again.

If I understand correctly, the only way to force my app to use an environment using the 5 repos with the setup config would be to delete the 5 repo variant in the Cursor web admin so it is forced to recreate it next run.. Is that right? I would like some way to remotely force a refresh on an environment to say “Use the most current version because I added the config” or “create a new environment with the name ‘Product Environment with Setup’, which forced a new environment created with current repo that now has config” or “remotely delete this outdated environment so a new one can be created with more up-to-date repo variations”.

Does that make sense? I can see, not just for me, how having the ability to control those environments (create with name, delete existing environment, force update existing environment) to bring an environment up to date and using a new config. I don’t see any of those capabilities now if I understand correctly. Is that right? Is that something that could be added sometime in a future release?

8

Almost, but deleting isn’t the only option. There are three ways to bring a 5-repo environment up to the current config:

  • Edit it in the dashboard: open the environment and point its config to .cursor/environment.json from the main repo. It’ll update in place, no need to delete it. After that, runs via repos[] will reuse the already updated config.
  • Rename it and select by name: give the environment a name via ⋯ > Rename, then run with env: { "type": "cloud", "name": "<name>" } and without repos. This is the most predictable option for programmatic control because you explicitly choose which environment to use.
  • Delete and recreate: also works. Delete it in the dashboard, and the next multi-repo run will recreate the environment and pick up .cursor/environment.json since the file is now on the default branch.

So your understanding is correct, but full deletion is just one option. Editing the config in the dashboard achieves the same result without recreating anything.

On the second part, managing environments from the SDK right now (create with a name, delete, force refresh) isn’t available. It’s web UI only. This is a real gap and I’ve forwarded it as a request. I can’t share an ETA, but similar requests are already tracked here if you want to add a vote or details:

Let me know how the environment update goes.

9

So, I did add the context in the cursor backend.

I ran through my taskboard about 5-10 tasks today. Most took 3-6 min, then this last one took almsot an hour. I am not sure why that happens. If you can take a look, for an example.
Here are some examples of tasks I ran today all after setting the env data in the backend like you suggested.

I just don’t understand how much larger, more complicated tasks are taking 2-3 min, and then a simple, single action task then takes 41 min. On my windows installed local cursor, I am not sure any task ever has taken 40 min, so it’s crazy that “Hey this dropdown popup isn’t showing anything now.” takes 41 min for a front end visual bug. It feels like there is something else going on because the average task is taking 2-3 min.

Task 56 - Cursor Cloud Agent completed in 2 min 54 seconds. 2 repos contained changes.
Description Text: Let’s move the “Tags” into the “Board Settings” area and rename it to “Manage Tags”
Acceptance Criteria Instructions :

1. Move the manage “tags” area into the “Board Settings” and remove it from the top right sub nav area to reduce option overload for users.

  1. Let’s hide the “Calendar” and “Table” options in the sub nav for now, we aren’t likely going to use it and it will redice option overload for users.

  2. Make “Board” the first option in the sub navigation and Timeline be second.

  3. In the “Board Setting” add the “Manage Tags” area here and name is that instead of just “Tags” This option should live here as a management option instead of something a user would interact with daily.

  4. Let’s remove the ? help icon in the top (just hide it) for now. We don’t want users being directed to the setup AI agents as all of those informational areas should be hidden and inaccessible from anyone where thos epermissions were not added to the board or a super admin.

Task 57 - Cursor Cloud Agent completed in 3 min 06 seconds. 2 repos contained changes.
Description Text: Some changes for the bucket options multi select for automations. New bug after deleting. See AC below. Also changes for how the + buttons look and function at the bottom of each bucket. See AC below.
Acceptance Criteria Instructions :

1. I deleted a few old “automations” and added new ones and that caused the multi-select box in the bucket options to be visually bad. The dropbox is no longer aligned with the dropbox. It’s like 75 to 100 px below it and to the right.. If a bucket has scroll ability that dropbox should align with whever the dropbox is when it’s clicked.

  1. Let’s move the + button at the end of each bucket to add a new task card to be jsut under the last task card. I want the style to be like the “+ Add Bucket” with purple background and white + text. Also if the bucket is too long and thus a scrollable bucket, then the plus button sticks to the bottom like it does now.. so if a buckets tasks are short, it pulls the button upwards, but if the tasks buket scrolls because lots of tasks, then the + butotn should always be visible (not need to scroll down to the bottom to see it).

Task 58 - Cursor Cloud Agent completed in 3 min 16 seconds. 3 repos contained changes.
Description Text: I deleted 2 automations because we added functionality to them and I needed to re-create them. I re-added the new automations. We have 4 now, and 1 triggers when development finishes, 1 triggers when something is moved into Push to PRoduction and 2 are “run from the Task”. When open a bucket option menu, I see 4 options, and they all say the same thing.. 2x “Merge feature branch into Origin” and 2x “Merge origin into Master” but that isn’t the name of any of the 4 I currently have in Automations.
Acceptance Criteria Instructions :

  1. We need to make sure when we delete an automation, it’s removed from any board it was being used in.

  2. The styling on the dropdown box in the bucket settings for “select automationo” is pushed way down from where the dropbox on the screen.. so the box that pops up is liek 100px below and the the right if the thing I clicekd on and I can’t even see the last 2 options because they are off the bottom of my desktop screen.

  3. The only options that should show for what can be ran “manually” in a task card are the ones that say “Run From Story” so I shoudl only see 2, and their names shoudl reflect what they do more.. because now we have the option to merge and git pull or just merge.. on each environment so these aren’t descriptive to what they do when viewing them in the task bucket settings.

  4. When DID drag a task over to “Push to Production” it did not merge Dev into Master nor did it do a git pull. If a automation is setup and attached to a bucket in the Automation settings, then that shouldn’t also need to be attached to the bucket in the bucket settings. If we tell the system to automatically run something when it drops into X bucket, then it should.. I wonder if right now you ALSO have to come to the bucket and then attach that as an “Allowed Automation”. The “Allowed Automatons” shoudl only be for ones you plan to run by hand. Any o the “automatic” ones like “when development finishs” or “when task is put into bucket” should run when that thing happens.

Task 59 - Cursor Cloud Agent completed in 1 min 05 seconds. 2 repos contained changes.
Description Text: After last change, now in the Bucket Options menu the “Allowed Autoation” doesn’t display anything when you click on it. I can see when clicking on it that it does add a division in the DOM and that there are two options but nothing visually is on my screen. See AC below.
Acceptance Criteria Instructions :

  1. Expected behavior is that when you click on that drop down that the drop down box pops up just like it does anywhere else on the website. Currently when I click on it the icon changes and Dom I can see an element is added but visually I can’t see it .

Task 60 - Cursor Cloud Agent completed in 41 min 03 seconds. 2 repos contained changes.
Description Text: On when in the buket options popup, the “Allowed Manual Automations” dropdown still does not show anything when clicked. There should be 2 results on this taskboard showing up. There is no popup at all.
Acceptance Criteria Instructions :

  1. Visually the pop up on a browser is not showing. Click the 3 dot menu on a bucket and when the options popup opens, scroll down and click the dropdown for “Allowed Manual Automatons”. Expected result is to see a menu but visually there is no menu. Please look at other dropdowns from the site (like the Task Cards “Playbook” dropdown) and see how that loads and emulate that functionality.
10

Glad the env config tweak helped. Most tasks are now finishing in 2 to 3 minutes, which is what we expect.

About the 41-minute run. This is not spin-up time, yours is consistently fast, and it is not the env config either. It is the agent runtime itself. A couple common reasons for this kind of variance:

  • Visual and frontend bugs like “the dropdown isn’t showing” often make the agent spend a lot of time driving the browser, opening the page, taking screenshots, and re-checking the result again and again. On tasks that are hard to verify, the agent can get stuck in a verification loop, which turns seconds into minutes. By the way, Task 59 and Task 60 are basically the same visual bug, and the run got much longer on the retry. We’re tracking this pattern. Here’s a related thread: Agents getting slower because of browser checks
  • The longest runs are usually the ones where the agent delegates work to multiple cloud subagents one after another. A narrower task request helps a lot here.

To dig into Task 60 specifically, please send the agent/run ID in the bc-... format. With that we can check where the time went in that run.

11
bc-54b5cfc9-567f-4707-9ad2-8551e70aab1c

That shoul d be what you need. I guess the Cursor Cloud AI agents work differently at a base than a windows installed Cursor IDE. It will do things innately that locally installed Cursor wouldn’t and those things might be causing super slow runtimes in certain instances.

The page I am talking about is behind a login wall. So if it tried to pull it up on a browser, it would need production credentials to login and test that, so unless it setup a local environment and DB so it could manipulate the password and login, it would just load a browser, and try to go to the page and it woudln’t be able to see anything because it’s not logged in. I wonder if because the AC told it to check.. that it kept trying to load the browser page but couldn’t ever do it?
15

You got it, that’s exactly it.

Here’s where the time went in this run: the agent finished the actual code fix in about 4 minutes, then spent the remaining about 44 minutes on two back to back browser verification sessions, first about 24 minutes, then another about 20, trying to visually confirm the dropdown fix. Neither session produced anything useful, which matches your theory: the page is behind a login wall, the agent couldn’t log in, so it kept trying, gave up, then started a second loop.

How to avoid this:

  • If browser verification isn’t needed, say it directly in the request. A line like “Do not attempt browser or UI verification, the app is behind a login” works, and \/no-test in the prompt is a shortcut that tells the agent to skip testing entirely. For your task board, you can auto add this to visual or frontend tasks.
  • If a visual check is needed, give the environment a way to reach the page, for example a local dev setup with a saved test account. When the agent can actually log in and see the UI, these checks are quick and useful.

Other than that, nothing else looks wrong with this run. Spin up was fast, and your environment config is now being picked up correctly.

This is the same verification loop pattern mentioned in the other thread: https://forum.cursor.com/t/agents-getting-slower-because-of-browser-checks/169791. We’re tracking it. Let me know how it goes with \/no-test.

16

Yes I’ve added that as a base rule not to do browser verification from here out.

However the base problem was that there was no way for me to really tell what was taking all that time up that I could see.

Is there a way to get a breakdown of things that the cloud agent tried to do and how much time is spent doing those things to return? I’m extremely appreciative for your time looking into this for me. If there was some sort of summary or breakdown of what the agent did that was returned or at least something in the sdk that gives access to this days, I might have been able to come to this conclusion without needing to come to the forums and take your time.

Thank you very much for helping me come to a conclusion of why these tasks were taking so long!

17

Glad you got it sorted. And yep, you can pull that kind of breakdown yourself via the SDK.

run.stream() in @cursor/sdk gives you a typed event stream while the run is happening, not just the final text. It includes everything you need to understand what the agent did and where the time went:

  • tool_call - tool name (edit_file, run_terminal_cmd, task for delegating to sub-agents, etc.), status (running/completed/error), plus args and result
  • thinking - includes thinking_duration_ms
  • assistant - text steps
  • usage - token usage
  • status - run lifecycle (CREATING/RUNNING/FINISHED/etc.)

If you add your own timestamp when you receive each event, you get a per-step timeline. You can see which tool calls and sub-agents ran and how long each one took. That’s exactly how those two 20+ minute computerUse stretches in Task 60 would show up. There’s an example of streaming events into a transcript in the SDK docs: Cursor TypeScript SDK | Cursor Documentation

Under the hood, it’s an SSE stream GET /v1/agents/{id}/runs/{runId}/stream with resume via Last-Event-ID, so you can continue if the connection drops.

What’s missing today is a single ready-made summary that includes per-step durations, number of files and lines changed, and cost in one field. For now, you need to aggregate it from the stream yourself. A durable run summary with metrics is a request we’re tracking, here’s a related thread where you can add a vote and details: Feature request: Cloud Agents API live activity stream, stable events, and run summary for third-party chat UIs

Try wiring streaming into your task board, it’ll give you exactly the diagnostics you were missing. Let me know if anything doesn’t work.