Ultra Cloud Agent VM recycled 4× in 2h (disk wiped) — related to Tyler’s VM reset

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

On Ultra, a long-running Cloud Agent keeps having its VM forcibly recycled/replaced with no dashboard reason. The agent stays RUNNING / not killed, but ephemeral disk is wiped (tmux, caches, secrets).

Same class of failure as Tyler Harden / @durden: topic 164007 — “VM reset/replaced and lost logs and output artifacts”

Confirmed 4 recycles in ~2 hours tonight. Each new boot shows dmesg: “random: crng reseeded due to virtual machine fork”. Events show later “Environment setup completed” but no recycle/OOM/idle reason. Shell: Pod terminated exit 4294967295.

Steps to Reproduce

  1. Start a long-lived Cloud Agent (ours: mobile-origin, multi-day bcId).
  2. Run a multi-hour tmux job writing local disk + pushing to S3.
  3. Within ~20–40 minutes the pod disappears.
  4. A new VM boots under the same bcId; local state is empty; conversation continues.

Expected Behavior

While a Cloud Agent is RUNNING, the VM should stay up (or show a recycle reason), and long jobs should not silently lose tmux + disk on host moves.

Operating System

Other

Version Information

Cloud Agent (not local IDE).
Plan: Ultra
Agent URL: https://cursor.com/agents/bc-019fe335-ac57-720c-8ad1-96968b5fac04
bcId: bc-019fe335-ac57-720c-8ad1-96968b5fac04
Repo: gitlab.com/iliaskarim/HATrader
Launch source: mobile
Status across recycles: RUNNING, isKilled=false
Environment: repo .cursor/environment.json (JIT / build=null observed)
VM note: SWAP_SIZE_MB=0
Client: Cursor for iOS + web agents UI

For AI issues: which model did you use?

Auto / default Cloud Agent model (issue is VM infra, not model output)

For AI issues: add Request ID with privacy disabled

bc-019fe335-ac57-720c-8ad1-96968b5fac04

Additional Information

Timeline UTC 2026-08-15:
~20:21 started long tmux backfill
~20:47 recycle #1 (vm fork; disk wiped)
~20:53 restarted
~21:12 recycle #2 (exit 4294967295)
~21:46/21:48 recycle + restart
~22:19 recycle #3
~22:22 restarted
~22:31 recycle #4 (vm fork again)

Ruled out: user kill, obvious OOM, disk full.
Impact: multi-hour Ultra Cloud Agent jobs unreliable; secrets must be re-pasted; only S3 survives.

Ask: root cause on this bcId; idle vs preemption vs max lifetime; surface recycle reasons in events; sticky disk / long-job path.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Update: started a brand-new Cloud Agent to test whether only the multi-day bcId was affected. The new agent’s VM also recycled within minutes. So this is not limited to long-lived agents.

7

Hey @IliasKarim!

The VM isn’t being arbitrarily recycled. The multi-hour python backfill is exhausting the Cloud Agent pod’s memory (16 GB RAM, no swap). The guest kernel OOM-kills the job and the VM’s control daemons, the pod dies, and the agent recovers onto a fresh VM.

Conversation and pushed git survive; ephemeral disk (tmux, caches, secrets) does not. The crng reseeded due to virtual machine fork dmesg line is expected on every boot — pods start from forked snapshots — and isn’t evidence of a fault.

We’re already tracking this failure mode, including surfacing recycle reasons in dashboard events.

Short term: keep peak RSS well under 16 GB (batch/stream the backfill), and keep checkpointing to S3 / committing early so a recycle doesn’t wipe the run.