What is this?
A dedicated runtime for AI agents: it runs multiple agents and sessions inside a Kata-isolated VM and adds workspace isolation, checkpointing, rollback and observability on top of it.
A dedicated runtime for AI agents: it runs multiple agents and sessions inside a Kata-isolated VM and adds workspace isolation, checkpointing, rollback and observability on top of it.The name says OS — is this something I install on a machine like a Linux distro?Not a desktop OS: it builds a guest kernel, rootfs and trusted services that run inside a Kata VM, forming a trusted execution environment for agents. Kata is only the current backend, not a fixed part of the architecture.
Not a desktop OS: it builds a guest kernel, rootfs and trusted services that run inside a Kata VM, forming a trusted execution environment for agents. Kata is only the current backend, not a fixed part of the architecture.So how do I actually drive it — is there a CLI?Mid-migration, so no polished install yet: you drive the in-guest allox-workspace-daemon via its RPC API at /v1/rpc (agents, sessions, checkpoints, rollback, tracking). The user-facing CLI wrapper lives in the separate allox-cli repo.
Mid-migration, so no polished install yet: you drive the in-guest allox-workspace-daemon via its RPC API at /v1/rpc (agents, sessions, checkpoints, rollback, tracking). The user-facing CLI wrapper lives in the separate allox-cli repo.What does it need under the hood — will any machine do?It's Linux-only by construction: a Kata backend for VM-level isolation, Btrfs for session workspaces, Bubblewrap namespaces and per-session cgroups in the guest, plus an optional eBPF process tracker.
It's Linux-only by construction: a Kata backend for VM-level isolation, Btrfs for session workspaces, Bubblewrap namespaces and per-session cgroups in the guest, plus an optional eBPF process tracker.What can't it do yet?User and network namespaces plus fine-grained egress policy are future work, so outbound traffic isn't sandboxed yet. VM-level snapshot/restore is also a separate, coarser operation than a session rollback.
User and network namespaces plus fine-grained egress policy are future work, so outbound traffic isn't sandboxed yet. VM-level snapshot/restore is also a separate, coarser operation than a session rollback.Is it open source, and can I use it commercially?Yes — Apache-2.0, so it's free for personal and commercial use.
Yes — Apache-2.0, so it's free for personal and commercial use.How does it keep one agent from stomping on another?Each agentid/sessionid pair gets its own cgroup and a Bubblewrap sandbox: PID/mount namespaces, a minimal file view and a private /tmp. Agents drop all Linux capabilities before starting, and every subprocess inherits the cgroup, so the control plane can attribute processes and, if needed, kill a session's whole process tree.
Each agentid/sessionid pair gets its own cgroup and a Bubblewrap sandbox: PID/mount namespaces, a minimal file view and a private /tmp. Agents drop all Linux capabilities before starting, and every subprocess inherits the cgroup, so the control plane can attribute processes and, if needed, kill a session's whole process tree.If a session goes off the rails, what does rollback actually undo?Only that agent+session's Btrfs workspace — other agents, other sessions and the runtime itself stay untouched, while checkpoint indexes, audit events and transaction logs are kept outside the rollback scope. Killing the session's tracked processes first is optional ('killprocesses': true or the --kill-session-processes-on-rollback default).
Only that agent+session's Btrfs workspace — other agents, other sessions and the runtime itself stay untouched, while checkpoint indexes, audit events and transaction logs are kept outside the rollback scope. Killing the session's tracked processes first is optional ('killprocesses': true or the --kill-session-processes-on-rollback default).Do I have to checkpoint manually, or does it happen by itself?It can be automatic: an agent framework publishes session/turn lifecycle events to the guest interface, and the daemon then creates a baseline checkpoint when the session starts plus one after every successfully finished turn. The policy must be disableable per agent or session.
It can be automatic: an agent framework publishes session/turn lifecycle events to the guest interface, and the daemon then creates a baseline checkpoint when the session starts plus one after every successfully finished turn. The policy must be disableable per agent or session.Can I tell which running process belongs to which agent?Yes, with the opt-in eBPF process tracker: a separate native collector hooks kernel sched tracepoints and records fork, exec and exit, propagating which agent and session a run belongs to. It's off by default and must be explicitly enabled as a new OS service interface.
Yes, with the opt-in eBPF process tracker: a separate native collector hooks kernel sched tracepoints and records fork, exec and exit, propagating which agent and session a run belongs to. It's off by default and must be explicitly enabled as a new OS service interface.What are similar projects?nvx, gvisor, quicksand, runc, firecracker, capsule-fs, virtio-nvgpu, CubeSandbox
nvx, gvisor, quicksand, runc, firecracker, capsule-fs, virtio-nvgpu, CubeSandboxWhich topics is it in?snapshot, hypervisor, ebpf, filesystem, rpc, runtime, kernel, virtualization, infrastructure, sandbox, observability, agent
snapshot, hypervisor, ebpf, filesystem, rpc, runtime, kernel, virtualization, infrastructure, sandbox, observability, agent