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

[lingdie]

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.

[lingdie]

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]

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]

Interesting thread. We've been working on a similar problem space with 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.