Cloud Agent running for >1 hour just disappeared, VM reset/replaced and lost logs and output artifacts. I have a cloud agent that is running a Python script running API calls and doing a bulk import of data into our API. Have been iterating on this for a few weeks. This is my first time where after an hour or so of it running and logging in the cloud Terminal via tmux, suddenly the VM has reset or been replaced, and I have lost the terminal sessions, files, etc. and the agent is oblivious to what happened.
Steps to Reproduce
Not sure how to describe this without disclosing confidential info publicly.
Expected Behavior
My cloud agent sessions should exist indefinitely until I am done with them or archive them, etc. Or it should be clear with warnings that the VM it is running on is going to randomly get deleted or disappear mid session.
Operating System
MacOS
Version Information
Cursor Cloud Agent.
For AI issues: which model did you use?
Auto Mode
For AI issues: add Request ID with privacy disabled
Hi @durden, Thanks for the post, and I apologize for this problematic behavior. looked into this agent: the VM it was running on was lost on our side mid-session and rebuilt as a fresh machine from your environment snapshot. Your conversation state was restored automatically (so the agent kept going), but anything that only lived inside the old VM, including your tmux sessions, the ongoing process, and any uncommitted files, wasn’t carried over.
We’re working hard to make cloud agents more resilient but recognize that we still have some gaps like this one you’ve experienced.
To make long jobs more resilient in the meantime:
Commit work to your branch often. Committed git state survives a VM rebuild; uncommitted files are most at risk.
Checkpoint progress for long bulk jobs so a restart can resume instead of starting over.
Avoid relying on detached background or tmux processes to keep running on their own, since they live and die with that specific VM.
My second time running into a cloud agent that just lost it’s terminal & VM environment in the middle of a run for no reason.
Steps to Reproduce
Run a cloud agent with a long-running tmux session logging the actions. It will spontaneously lose connection to the env/VM will terminate. Unable to resume. Files/Artifacts become lost.
Expected Behavior
A cloud agent should be persisted and exist while it is actively running, it should not be ephemeral while it is running.
@Colin You merged and closed a bug report that is a unique and different instance of this occurring, under different circumstances (much sooner, unrealistic termination window). I’d appreciate the opportunity for support to review this bug report standalone, versus having it swept up as a non-issue. This is seriously blocking for myself or anyone running workloads on Cursor Cloud Agents. This is legitimateley a bug.
Hi @durden You’re right that this is a real issue, and it wasn’t anything you did. Looking at agent bc-bed0fbd2-3ea3-4647-bbbe-55514a4a5f77 on July 6, the environment was actually lost twice that day:
In the morning, the machine backing the agent was cleaned up on our side mid-session. The agent recovered onto a fresh machine, and your working branch was restored.
A few hours later, the replacement machine stopped responding and, after about 30 minutes of failed retries, was replaced as well. Your post came in right in the middle of that window. This second failure is a different mechanism from your June incident, and we’re tracking it separately with the engineering team rather than folding it into the earlier report.
In both cases the conversation and your committed git state carried over, but the tmux session, the running import process, uncommitted files, and output files that lived only on that machine did not. I understand the pain of this failing.
Two things are actively being worked on that map directly to your reports: improving how long-running agent environments survive this kind of disruption, and letting run outputs persist across an environment rebuild so they aren’t tied to a single machine. Your agent IDs are attached to that work as concrete data points.
Until those land, the guidance from last time unfortunately still stands: committed and pushed work is the only state guaranteed to survive, so frequent commits and resumable checkpoints are the safest way to run long imports.
Thank you for reporting and I apologize for the inconvenience here.
Thanks @kevinn. I would be curious to know more about the agent infrastructure and resiliency here (if it’s proprietary or part of your moat, obviously I can respect that). But out of my own curiousity and interest, I had been wondering what kind of “DevAgentOps” I could implement, perhaps in a shared pool here locally, for resilient agent VMs. Is this something accomplishable with Kubernetes or other virtualization? I have succeeded at this in the past with microservices, DBs, and virtualized network hardware (MikroTik Router OS, Proxmox SDN gateways), and years ago saw some success with live machine to machine movement of a VM in a frozen state without losing the stack/heap, seamless handoff basically.
I’d like to see something like that for durable Cloud Agents, and would be happy to contribute/test, or explore this for my own pool of agents to handle this use case specifically. Perhaps this is more appropriate conversation for a DM.