The choice to use VMs instead of docker/container runtimes seems like the right tradeoffs to me as well. Afaict most of the docker runtimes mount the entire macOS home directory into the shared VM, so if the container runtime is escaped the VM is unnecessarily providing access to the entire home directory.
Silo uses Apple Containers (or Docker if unavailable). Needing to use macOS Tahoe isn't a concern to me personally, and I like the decisions made in its design to support Dockerfiles for building the VMs, minimal init and kernel, and the intentional focus on minimal access isolation: https://www.youtube.com/watch?v=JvQtvbhtXmo.
I briefly explored the possibility of compiling an agent tool to WASM and running on WASI for a portable sandbox that doesn't involve container or VMs, but then saw all the hoops necessary for making networking calls from WASI (preview 2 yada yada) and ran away
Afaict most of the docker runtimes mount the entire macOS home directory into the shared VM
Docker Desktop has "virtual file shares" in settings under Resources -> File sharing and defaults to sharing /Users, but it's a little unclear to me what this is doing. The /Users directory doesn't appear available to me by default in any dev containers I've built.
the "I tried Vagrant but it looked like too much of a project" line was a little weird when later on the other alternative is QEMU directly, but these are different layers? You can use the QEMU driver in Vagrant.
Anyway the note about QEMU and virtiofs was interesting to me.
leighmcculloch | 16 hours ago
The choice to use VMs instead of docker/container runtimes seems like the right tradeoffs to me as well. Afaict most of the docker runtimes mount the entire macOS home directory into the shared VM, so if the container runtime is escaped the VM is unnecessarily providing access to the entire home directory.
I built something similar to Vibe in Go for my own workflows: https://github.com/leighmcculloch/silo
Silo uses Apple Containers (or Docker if unavailable). Needing to use macOS Tahoe isn't a concern to me personally, and I like the decisions made in its design to support Dockerfiles for building the VMs, minimal init and kernel, and the intentional focus on minimal access isolation: https://www.youtube.com/watch?v=JvQtvbhtXmo.
ocramz | 15 hours ago
I briefly explored the possibility of compiling an agent tool to WASM and running on WASI for a portable sandbox that doesn't involve container or VMs, but then saw all the hoops necessary for making networking calls from WASI (preview 2 yada yada) and ran away
jamesgecko | 6 hours ago
Docker Desktop has "virtual file shares" in settings under Resources -> File sharing and defaults to sharing
/Users, but it's a little unclear to me what this is doing. The/Usersdirectory doesn't appear available to me by default in any dev containers I've built.rsalmond | 19 hours ago
Since the docs don't mention it anywhere, for those wondering how it works it seems to make use of the MacOS
VZVirtualMachineinterface.https://developer.apple.com/documentation/virtualization
bedrovelsen | 12 hours ago
Says the human or the "remove emoji from anywhere in this repository" prompt ;)
sme | a day ago
Can you explain how this differs from https://michael.stapelberg.ch/posts/2026-02-01-coding-agent-microvm-nix/ and pros/cons of the approach?
adamcstephens | 17 hours ago
A big pro for this tool is you don’t need to know and configure nixos.
ocramz | 17 hours ago
interestingly for such projects, there is a discussion on various alternative attempts: https://github.com/lynaghk/vibe/?tab=readme-ov-file#alternatives
scraps | 15 hours ago
the "I tried Vagrant but it looked like too much of a project" line was a little weird when later on the other alternative is QEMU directly, but these are different layers? You can use the QEMU driver in Vagrant.
Anyway the note about QEMU and virtiofs was interesting to me.
mdaniel | 14 hours ago
It also was a victim of the great big rug pull, if that matters: https://github.com/hashicorp/vagrant/blob/v2.4.9/LICENSE (BuSL-1.1)