GitHub Issue

Question: Any plans to support persistent sandbox/workspace data?

Discovered On Mar 20, 2026

Primary Metric open

Hi, First of all, thank you for open-sourcing Zeroboot. The copy-on-write VM forking approach is very interesting, especially for AI-agent workloads. I had a question about the roadmap: are there any plans to support persistent sandbox or workspace data in the future? From my reading of the repository, Zeroboot currently seems optimized for extremely fast ephemeral execution from a prebuilt snapshot, which makes a lot of sense for short-lived isolated tasks. I was wondering whether you are also considering a model where users could preserve state across executions, for example: - persistent workspace directories - writable volumes mounted into sandboxes - snapshot/restore of user workspace state - resumable sessions instead of fully ephemeral forks I’m asking because this would make Zeroboot much more compelling for longer-running agent workflows, coding environments, and iterative development tasks. If this is already being considered, I’d be very interested to know: - whether persistence is part of the planned roadmap - what form you think it might take - whether the current architecture is intended to support that eventually Thanks again for the project.

View Raw Thread

Developer & User Discourse

lingdie • Mar 20, 2026

If this feature is on the roadmap and collaboration would be welcome, I’d be very interested in supporting it if circumstances permit. I’d be happy to help with use cases, design discussion, testing, or other practical contributions if that would be helpful.

chwzr • Mar 20, 2026

Mounting Host dirs into the vm is possible.
Some inspiration could be taken from bake: https://github.com/losfair/bake/blob/main/src/fileshare.rs

congwang-mk • Apr 1, 2026

Interesting thread. We've been working on a similar problem space with [sandlock](https://github.com/multikernel/sandlock), which takes a different approach (Landlock + seccomp instead of VMs). A few things that might be relevant to what you're describing:

- **Copy-on-write filesystem** with configurable exit behavior (`COMMIT` to persist changes, `ABORT` to discard) , so workspace state survives across runs without snapshotting a full VM
- **Checkpoint/restore** — captures full process state (registers, memory maps, FDs) and resumes from it
- **Pause/resume** API for session-like workflows
- Writable directories via `fs_writable` for persistent workspace mounts

Different tradeoff than VM snapshots (weaker isolation boundary, but no KVM dependency and ~7ms startup), which may or may not fit your use case.