I’m experimenting with setting up the environment for Cloud agents using environment.json and a Dockerfile.
One of my attempts was successful (no errors during docker build and no errors in the install script) and a snapshot of the environment was saved.
Now when I start a new chat with an agent, the environment is always restored from that snapshot, despite the fact that I’ve already pushed some changes to the Dockerfile and to the install script (but not to the environment.json itself - maybe this is the problem?).
I tried waiting for ~8 hours, I tried to create a separate branch with the changes, nothing helped.
How do I force the environment to rebuild?
Update: I did try to make a noop change to my environment.json just to make sure I see the latest version in “Cloud Agents > Environments” settings. It still did not force the full rebuild from the latest Dockerfile and restored from the old snapshot again. That actually made things worse because now it used the latest install script, that depends on the latest Dockerfile, and the install script failed with errors.
Hey, this is a known limitation in the web flow. After the first successful build, a saved environment can keep restoring from an old snapshot even if the Dockerfile and install script in the repo were updated. There isn’t a force rebuild button in the UI yet.
What usually works as a workaround:
Open https://cursor.com/dashboard/cloud-agents > Environments, delete the saved environment for this repo, then create it again. This forces a fresh build with the latest Dockerfile.
Make sure all changes are committed and pushed to the branch the agent starts from. Cloud agents use the config from the commit they start on.
If that doesn’t help, try starting the agent from a brand new branch that has never had an environment created before.
We’re tracking this bug, but I can’t share an ETA for a fix yet. Let me know if recreating the environment helped.
Hey, thanks for the report. This is the same known issue as in that thread. After the first successful build, the saved environment keeps restoring from an old snapshot, and there’s no force rebuild option in the UI yet. I can’t share an ETA for the fix.
The fact that you don’t see the option to delete the environment at all is a separate known gap, we’re tracking that too.
To look into your specific case, please share:
Your Cursor version and account type, personal or team.
The Agent ID bc-… from a run where the old environment got pulled in, or the Request ID.
As a workaround while deletion isn’t available, try creating an environment for a completely new repo or a fork that has never had a saved environment, then check if it pulls the new Dockerfile there. This will help us tell if the issue is cache for a specific repo or something broader.
I am using a personal account and I am using the Web UI, not sure what version you are looking for.
Here is the request ID of a session that uses the wrong image: bc-9721837b-569f-4964-899d-7ec8525a0f74 (I have many of those, just picked a random one)
Here is a session with the setup agent that seems to have been successful, but does not change anything: bc-3d15488e-5a66-4f22-9839-853c53a84e29
Thanks, the info and screenshot helped. A few notes:
On deleting the environment: in your screenshot, on the right side of the environment row, there’s a ... menu (three dots). Open it, Edit and Delete are usually there. If Delete isn’t there, that’s the known issue where the UI is missing the delete button. We’re tracking it, no ETA yet.
On the main issue (an old snapshot gets restored instead of rebuilding from the updated Dockerfile): yep, that’s a known bug in the web flow. After the first successful build, the saved environment can keep restoring from the old snapshot even if the Dockerfile and install script in the repo were updated. I can’t share a fix timeline yet. I’ll attach the bcId you sent to the report.
One cache detail: a rebuild triggers when the Dockerfile itself changes, but NOT when files that are COPY-ed into it change. If you only changed those files and not the Dockerfile, the snapshot might not have been invalidated for that reason.
Can you tell me if the test with a new repo or a fork that has never had a saved environment worked? Does it pick up the fresh Dockerfile there? This will help confirm whether it’s repo-specific caching or something broader.
Hey, quick update on this thread. Cloud Agent environments now work via Builds, and that changes how the environment gets updated, which matches your original request about how to force a rebuild.
What matters:
The environment rebuilds on a schedule, and also every time you save config changes.
You can start a build manually anytime. Go to the Builds tab in the Cloud Agents dashboard and click Trigger build. The build uses whatever is currently in the repo, including the Dockerfile and install script.
Extra good news re the broken install. If a new Build fails, agents will keep starting from the last successful one. A failed build won’t overwrite a working one.
Try running Trigger build and check if it picks up the latest Dockerfile and install changes, and that it’s no longer pulling the old snapshot. If everything looks good, no need to reply. If the stale snapshot still reproduces with Builds, let me know, and please start a separate thread so we can dig in faster.
