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
I've been exploring eve's sandbox lifecycle and noticed that containers currently persist indefinitely. As sessions accumulate, this leads to container sprawl and ongoing resource consumption. I'd like to propose an alternative model that keeps user files safe while letting idle containers be reclaimed automatically.
Proposed approach
Separate compute from state:
At session start, mount a per-session directory from the host into the container as the working directory
Tell the model explicitly (via instructions) that only files inside this directory are persisted across sessions
Apply a configurable idle TTL to containers — auto-remove them after a period of inactivity (e.g. 30 minutes)
When a session resumes, spin up a fresh container and remount the same host directory — the user's previous output is still there
Relationship to agent/workspace/
This proposal is orthogonal to agent/workspace/. The workspace directory seeds static, authored files at session start (templates, tooling configs, etc.). The host-mounted workdir targets dynamic, user-generated output that should survive container teardown. Both can coexist naturally: the container receives workspace seeds on startup and uses the persistent mount for runtime output.
Why this might be worth considering
Eliminates container sprawl without sacrificing user files
Stateless compute, stateful storage — a cleaner model that's easier to reason about and scale horizontally
Fresh environment on reconnect — a new container every session means no stale processes, leaked env vars, or accumulated side effects from previous runs
Sandbox integrity is preserved — process isolation, network policy, and filesystem boundaries remain fully intact. The mount is an explicitly authorized path, not a hole in the isolation model
Risks and mitigations
Bidirectional mount: writes inside the container land directly on the host path. A misbehaving agent (e.g. aggressive chmod, symlink traversal) could affect the host-side directory. Mitigations: launch containers with --security-opt no-new-privileges, ensure the host-side owner is an unprivileged user, and scope each mount to an isolated per-session path.
TTL tuning: too aggressive and users lose a live environment mid-task; too conservative and containers aren't reclaimed meaningfully. A configurable TTL with a sensible default (e.g. 30 min) and a clear reset-on-activity behavior would cover most cases.
Behavior change for existing users: users who rely on returning to a live container would be affected. An opt-in flag or gradual rollout would be worth considering before making this the default.
Summary
The core idea is to treat containers as ephemeral compute units and the host-mounted workdir as the durable artifact store. This mirrors how modern stateless backends work and seems like a natural fit for eve's durable-by-design philosophy.
Happy to discuss further or sketch out a more concrete design if this direction seems interesting.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Background
I've been exploring eve's sandbox lifecycle and noticed that containers currently persist indefinitely. As sessions accumulate, this leads to container sprawl and ongoing resource consumption. I'd like to propose an alternative model that keeps user files safe while letting idle containers be reclaimed automatically.
Proposed approach
Separate compute from state:
Relationship to
agent/workspace/This proposal is orthogonal to
agent/workspace/. The workspace directory seeds static, authored files at session start (templates, tooling configs, etc.). The host-mounted workdir targets dynamic, user-generated output that should survive container teardown. Both can coexist naturally: the container receives workspace seeds on startup and uses the persistent mount for runtime output.Why this might be worth considering
Risks and mitigations
chmod, symlink traversal) could affect the host-side directory. Mitigations: launch containers with--security-opt no-new-privileges, ensure the host-side owner is an unprivileged user, and scope each mount to an isolated per-session path.Summary
The core idea is to treat containers as ephemeral compute units and the host-mounted workdir as the durable artifact store. This mirrors how modern stateless backends work and seems like a natural fit for eve's durable-by-design philosophy.
Happy to discuss further or sketch out a more concrete design if this direction seems interesting.
Beta Was this translation helpful? Give feedback.
All reactions