Local first is also a feature, for work you often can't run company code on a remote VM that isn't company owned. Remote dev envs are on the roadmap though, that's one of the reasons why I designed the declarative clawk.mod manifest
It was leveraging apple container in the first versions. They have the same foundation VZ (Virtualization.framework), build one container per VM. The reason I stayed with raw VZ instead of apple container is the network filtering feature
My pleasure! You can find my fork here: https://github.com/clawkwork/gvisor-tap-vsock — the diff is tiny, just a hook in the TCP/UDP/ICMP forwarders that consults an allow-list before dialing
There are two sides to this. The first is security, which plenty of comments already covered. The second, and the real one for me: my tests spin up Docker containers, and I was building a Kubernetes tool (argocd/flux style) that needs a real cluster in the sandbox. In a container that means Docker-in-Docker, which always felt hacky. A VM is just a normal Linux box where Docker and k8s run like they do everywhere else. A separate user can't give you that, it shares your one kernel and whatever's already installed on the host.
Hadn't seen yoloai before. I really like new/diff/apply/destroy workflow, that's interesting. For my own needs the two things I was after were multi-repo worktrees (one sandbox spanning several repos, each on with its own worktree) and a single network restricted VM path I fully control, rather than many backends (I started with many backends at first but it was awkward to add network filtering to them).
Lots of overlap though, nice work, and I'll be reading through yours.
Thanks! There's no packet firewall at all, no iptables/nftables. On macOS the VM's NIC is a Virtualization.framework file-handle device. The daemon runs gvproxy, which terminates the guest's connections and re-dials them as host sockets, so I filter with an allow-list right before the dial.
One caveat, since you asked about root specifically: that's the macOS path, and it only works thanks to the fd NIC. Firecracker on Linux only speaks a TAP, which needs root, so there I do shell out to sudo, but just for the device. The filtering is still the same userspace allow-list.
Launched today, this HN thread is the first public mention. Zero paying users yet, just finished building it over the past few weeks as a solo project.
If you want to try it: code `HNPRELAUNCH` on checkout, first month free, then 19€/mo (cancel anytime from your Stripe receipt). Limited to the first 20 redemptions, expires in a week.
The 19€/mo is infra only. Claude Code inside the VM signs in via OAuth to the user's own Anthropic account.
I'd love to explore bundling open models (Qwen, etc..) into the subscription down the line, but that needs product validation first, not going to ship something I'm not sure people actually want.
By setting aside the availability, it should be rememberable (for me it is either an animal or an object/person that represents the product/project).
Lately, I chose the name Sandglass for a message queue (https://github.com/celrenheit/sandglass). The reason is that this project depends on an ID generator that I named sandflake (in reference to twitter's snowflake).
So I chose the name sandglass because it is kind of like a glass with a lot of sandflakes flowing through it (like a message queue).
Another name I used was Lion for an http router but for no particular reasons :)
I worked mainly on open source side projects such as:
Sandglass https://github.com/celrenheit/sandglass a distributed, horizontally scalable, persistent, time ordered message queue. It was developed to support asynchronous tasks and message scheduling which makes it suitable for usage as a task queue.