Idle Container TTL + Persistent Host-Mounted Workdir

[xusenlin]

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:

• 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.

[ericlitman]

Did you take this further?

[HADIL19]

This separation between compute and state makes sense. One thing I wonder about is how eve currently tracks session ownership and cleanup. Would the container lifecycle manager need a persistent session metadata store (for example: session ID → workspace path → last activity timestamp) to safely recreate containers after TTL expiration?

Also, would it make sense to use object storage (like S3-compatible storage) instead of a host-mounted directory for the persistent workdir? That could make horizontal scaling easier if containers move between machines.