feat: default prime sandboxes to no lifetime timeout

[mikasenghaas]

Summary

• Default Prime VM sandboxes to no lifetime timeout: the runtime sends timeout_minutes=-1 (Prime's convention for an unbounded lifetime) instead of the previous 24h cap.
• Container sandboxes (vm=false) keep the fixed 24h lifetime (CONTAINER_LIFETIME) — only VM sandboxes support running without a limit.
• The lifetime is not configurable; it follows the sandbox mode.
• idle_timeout > 24h is now rejected only for container sandboxes; VM sandboxes accept any idle timeout.
• cap_remote_agent_timeout skips Prime VM configs (no lifetime to cap against); Prime containers and Modal keep the 24h cap.
• run() bounds the SDK's background-job poll at the container lifetime, or an effectively unbounded deadline for VMs.

Verification

• prime-sandboxes 0.2.37 against the live API: timeout_minutes=0 is rejected (422: timeout_minutes must be negative for infinite or >= 1); timeout_minutes=-1 creates a VM sandbox that reaches RUNNING and deletes cleanly.
• PrimeRuntime from this branch with the default config: sandbox came up RUNNING with timeout_minutes=-1 and was deleted on stop().
• Config validators: vm=false valid (24h lifetime); container idle_timeout > 24h errors; VM accepts any idle timeout; agent-timeout cap is a no-op for Prime VMs and caps containers at 24h.

Breaking

• Prime VM sandboxes no longer self-delete after 24h. idle_timeout (default 3600s) is now the only automatic cleanup for them; rely on it or delete explicitly.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes remote sandbox lifetime and timeout capping. Failed teardown can leave VMs running indefinitely except for idle_timeout.

Overview
Prime VM sandboxes no longer get a 24h hard lifetime. Create now sends timeout_minutes=-1 (provider “no limit”); containers still use a fixed 24h CONTAINER_LIFETIME.

Idle-timeout validation and cap_remote_agent_timeout only enforce the 24h ceiling for non-VM remotes (Prime containers, Modal, etc.). VM agent timeouts are left uncapped. run() polls with a 365-day deadline for VMs so the SDK still has a finite wait.

Breaking: VMs no longer self-delete after 24h. Cleanup is idle_timeout (default 1h) or explicit delete.

^{Reviewed by Cursor Bugbot for commit 69a7631. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Default Prime VM sandboxes to no lifetime timeout

• VM sandboxes are now created with timeout_minutes=-1 (provider convention for no limit) and polled with a 365-day timeout, effectively removing the lifetime cap
• Container sandboxes remain capped at 24 hours via CONTAINER_LIFETIME (renamed from MAX_LIFETIME)
• PrimeConfig._validate_idle_timeout skips the 24h upper-bound check for VM sandboxes; container sandboxes still enforce it
• cap_remote_agent_timeout in compile.py now exempts PrimeConfig with vm=True from the 24h agent-timeout cap and warning
• Risk: VM sandboxes with no lifetime cap can run indefinitely; reviewers should confirm PrimeRuntime.run in prime.py and cap_remote_agent_timeout in compile.py correctly gate which runtimes get the exemption

^{Macroscope summarized 69a7631.}