celrenheit

I tried it and it worked great at first but I had multiple issues with it, the disk space usage was growing significantly, I need to login multiple times for each sandbox, it's closed source and not possible to customize to my need.

One other thing, I want to be able to handle multiple repos in the same sandbox and have a standard workflow around worktrees (one worktree per repo, all the worktree mounted in the VM).

These were some of the reasons that led me to build: Clawk - https://github.com/clawkwork/clawk

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

No offense taken! Curious what your actual setup looks like, and whether you do any network filtering on the incus VMs?

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

That's actually how clawk runs it: the agent process (claude/codex) runs inside the Linux guest on a PTY, not on macOS

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

mostly macOS out of the box. I've tested it on linux and it worked but it's not my daily driver. I'll make the platform scope clearer in the README

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.

Thank you, that means a lot !

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.

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.

Shameless plug: https://clawk.work/

`ssh you/repo/[email protected]` → jump directly into Claude Code (or Codex) with your repo cloned and credentials injected. Firecracker VMs, 19€/mo.

POC, please be kind.

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 :)

tl;dr: Stellar distributed exchange and Ligthning Network coming in 2018

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.

Sandflake https://github.com/celrenheit/sandflake decentralized, sequential, lexicographically sortable unique id.

This looks promising