You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A client that creates a persistent sandbox is currently responsible for eventually deleting it. Process traps handle graceful exits, but a hard process termination, deleted workload pod, node loss, or disconnected orchestrator can leave the logical sandbox and its compute resources running indefinitely.
External reapers can encode expiry in labels and call the gateway later, but every orchestrator must then implement authorization, pagination, race handling, and lifecycle semantics independently. OpenShell should remain the owner of sandbox deletion and provide a first-class bounded lifetime for callers that need it.
Proposed Design
Add an optional server-managed expiration lease to sandbox creation.
CreateSandbox accepts either an absolute expiration time or bounded TTL. The default remains no expiration for backward compatibility.
The gateway persists the absolute expiry with sandbox metadata and returns it from get/list/watch APIs.
An authorized renewal operation extends the lease using optimistic concurrency so a stale client cannot shorten or overwrite a newer lease accidentally.
A gateway lifecycle reconciler selects expired sandboxes and invokes the existing DeleteSandbox lifecycle path. It must not delete driver resources directly.
Expiration is idempotent, bounded per reconciliation pass, observable through structured lifecycle events, and retried when driver cleanup fails.
Authorization to renew or remove an expiry follows existing workspace authorization.
A final re-read or resource-version precondition prevents stale expiry observations from deleting a renewed sandbox.
Driver-specific orphan cleanup remains responsible for resources that exist after the logical sandbox record is already lost.
The initial API can remain sandbox-scoped. Session-level TTL from #1884 and operator-owned lifecycle from #1719 can build on the same expiration primitive later.
Alternatives Considered
External label-based reaper. It works without API changes but duplicates lifecycle logic, requires broad administrative access for cross-workspace cleanup, and cannot guarantee consistent semantics across clients.
Kubernetes TTL or owner references. These are useful for Kubernetes-only deployments but bypass OpenShell's gateway lifecycle and do not cover Docker, Podman, or VM drivers.
Delete the Task-owned compute resources directly. This can leave gateway state, provider records, and workspace resources inconsistent.
Problem Statement
A client that creates a persistent sandbox is currently responsible for eventually deleting it. Process traps handle graceful exits, but a hard process termination, deleted workload pod, node loss, or disconnected orchestrator can leave the logical sandbox and its compute resources running indefinitely.
External reapers can encode expiry in labels and call the gateway later, but every orchestrator must then implement authorization, pagination, race handling, and lifecycle semantics independently. OpenShell should remain the owner of sandbox deletion and provide a first-class bounded lifetime for callers that need it.
Proposed Design
Add an optional server-managed expiration lease to sandbox creation.
CreateSandboxaccepts either an absolute expiration time or bounded TTL. The default remains no expiration for backward compatibility.DeleteSandboxlifecycle path. It must not delete driver resources directly.The initial API can remain sandbox-scoped. Session-level TTL from #1884 and operator-owned lifecycle from #1719 can build on the same expiration primitive later.
Alternatives Considered
Agent Investigation
mainat736e431dand latest release v0.0.96.Checklist