Arrakis: How To Build An AI Sandbox From Scratch

What does a coding agent need after it writes an application? Somewhere to execute it, inspect what happened and try again. Abhishek Bhardwaj approaches that problem through operating systems: after studying systems at Carnegie Mellon, he worked on WSL and a smartwatch OS at Microsoft, virtualization at Google, and infrastructure and RAG-based code chat at Replit. He introduces Arrakis as its solo founder and developer: an open-source execution and computer-use sandbox for AI agents.

Models such as o3 use tools during inference, including search and code execution. Reinforcement-learning workflows also need environments in which to execute reward functions at scale. For a coding agent, a full Linux environment adds something more useful than a function that evaluates a code string: commands such as ps and lsof let it inspect running processes and open files or sockets, diagnose an application and replan. That capability needs a security boundary. Generated code can be buggy or malicious, just like untrusted code copied from GitHub or Stack Overflow; running it on a host or production server puts both system privileges and customer data at risk.

The opening demonstration makes the execution loop concrete. Alongside familiar examples such as OpenAI Canvas and Claude Artifacts, Bhardwaj shows Manus responding to a request for a ChatGPT clone. It runs Linux commands, tries to launch the application and attempts repairs when something fails. His explanation is that models already possess substantial Linux knowledge from pretraining. A usable operating environment lets them apply that knowledge without requiring every debugging action to be encoded in a specialized agent framework.

Arrakis provides self-hosted, customizable sandboxes for code execution and computer use. Its central addition is snapshot and restore: an agent can save progress, attempt another step and return to the checkpoint instead of rebuilding the environment after a failure. The implementation is open source, making the execution boundary and the machinery behind that recovery available for inspection.

The runtime uses microVMs to isolate potentially hostile generated code. Latency matters too: a tool environment that takes too long to start slows the whole agent loop. Bhardwaj reports boot times below seven seconds for Arrakis, compared with forty seconds for a traditional VM on macOS. He also reports single-digit-second snapshots; a pending pull request targets boot below one second. Hardware, guest configuration, readiness criteria and snapshot sizes are unspecified for these figures.

The remaining features make the isolated machine practical to use:

• Service access: Arrakis manages port forwarding so applications and guest services can be reached through a public URL and port.
• Computer use: Chrome and a VNC server are preinstalled, exposing the browser's GUI to a remote client.
• Recovery: Snapshot and restore let an agent checkpoint a multistep workflow and return to an earlier environment.
• Client interfaces: A Python API, Go client, MCP server and OpenAPI-compatible YAML support both direct integration and generated clients.
• Customization: A Dockerfile determines the binaries and packages installed in the guest.

These are parts of one execution environment: isolation makes it safer to run code, while networking, desktop access and checkpoints make that code useful to an agent.

At the top of the architecture, a REST server creates and manages microVM sandboxes. Each sandbox contains a code execution server and a VNC server; forwarding makes those services accessible outside the guest. The Go-based Arrakis CLI and Python SDK are clients of this management layer, with MCP providing another integration path. The host must run Linux because the virtualization implementation depends on /dev/kvm, Linux's interface to hardware virtualization.

The API separates machine lifecycle from operations inside a machine:

The health endpoint is useful when placing the server in a distributed deployment. Python, Go, MCP and clients generated from the OpenAPI description all reach the same underlying management system. The next question is what boundary those managed machines actually provide.

Start with Linux's execution model. A thread is a schedulable unit represented in the kernel by a task_struct. A process groups threads that share resources, including an address space and page tables. The threads have distinct thread IDs while sharing a process identity—the thread-group ID commonly exposed as the PID. The kernel mediates privileged access to hardware so an arbitrary userspace instruction cannot simply take over the device. System calls cross that privilege boundary; the diagram uses int 0x80 to illustrate the transition into kernel mode.

Containers first solve a packaging problem. Suppose an application requires Python 3.8 and foo version 1.2, but the server has Python 3.9, 3.6 and 3.12, and no foo. Packaging the application with its dependencies makes it possible to run on that server without rebuilding the host's software environment around it. That is already useful for a sandbox expected to run arbitrary user applications.

On Linux, containers combine namespaces that scope resource visibility with cgroups that control resource consumption. PID, mount and network namespaces give processes bounded views of the machine. A container can see processes numbered 1, 2 and 3 even though those same tasks have different identifiers in the host's PID namespace. The host can inspect the child namespace; processes in the child do not gain a corresponding view of the host's process tree. Cgroups separately govern how much CPU or memory the workload can consume. A scoped view and a resource budget are different mechanisms, and containers need both.

Container processes still run directly on the host kernel. Namespaces logically group resources, but they do not give each container a separate kernel. If a process exploits a host-kernel vulnerability and obtains host-level privileges, the consequences can include reading other workloads' data, dumping memory or impersonating another identity. Container root by itself is not the same as host root; the danger here is an exploit that crosses the isolation boundary.

One response is to reduce the attack surface available to the process:

• Linux capabilities: Grant only the privileged operations the workload requires. Capability checks constrain which privileged paths a process can take.
• seccomp: Block system calls or filter their arguments, further reducing reachable kernel behavior.
• Minijail: Use a launcher and library to apply sandbox policies without hand-assembling every low-level API and error check.

Bhardwaj recommends Minijail from his Chrome OS experience. Its current threat model targets containment of known binaries and explicitly excludes safely executing attacker-controlled binaries or shared libraries, so it should not be treated as a complete arbitrary-code sandbox on its own.

Jailing remains valuable, but it does not remove all possible bypasses. For Arrakis's untrusted-code workload, the next layer is virtualization: place a guest kernel between the application and the host's virtualization interface.

A virtual machine has its own guest userspace and guest kernel. Applications make system calls into that guest kernel rather than directly into the host kernel. The host still supplies CPU, memory, storage and networking, but access passes through a different interface. The virtual machine monitor, or VMM, manages that interface; QEMU, crosvm and Firecracker are examples. On Linux, the VMM uses /dev/kvm to access the processor's virtualization facilities.

The VMM also supplies virtual devices, including block and network devices. Depending on the implementation, their backends can live in the VMM process or in separate sandboxed processes. A VMM thread may appear blocked from the client's perspective while it is actually running guest instructions in the processor's virtualization context. The device-access path in the walkthrough is:

1. Guest execution reaches an operation requiring host-side device handling.
2. A VM exit transfers control back to the host.
3. The VMM determines the reason for the exit and services the relevant device operation through the host.
4. The result becomes available to the guest, and guest execution resumes.

This transition is why a virtual machine's performance depends partly on how often its workload needs host-side intervention.

Bhardwaj characterizes CPU-bound execution under hardware virtualization as having essentially no penalty because guest instructions execute directly on the processor; he provides no workload-specific measurement for that characterization. Disk- and network-heavy workloads can incur more transition overhead. Keeping more state in guest memory can reduce some device access. Containers, by comparison, execute as native host processes, but retain the shared-kernel exposure that motivated the VM boundary.

MicroVMs retain hardware virtualization while shrinking and hardening the monitor around it. Bhardwaj traces the term and the first Rust-based VMM to the Chrome OS crosvm project. The security motivation for Rust is concrete: untrusted guest code interacts with emulated devices, and memory-safety bugs in their implementations can become escape paths. Rust reduces that class of implementation risk.

The crosvm architecture also isolates devices into separate jailed processes. A block-device process receives the permissions needed for storage operations; a network-device process receives those needed for networking. Compromising one backend should therefore leave the attacker with a narrower set of available operations. This per-device arrangement is a property of the described architecture, rather than a guarantee supplied by the word microVM.

The smaller footprint comes from supporting fewer things. QEMU serves a broad range of architectures and devices; the microVM monitors discussed here—crosvm, Firecracker and Cloud Hypervisor—focus on a narrower architecture and device set, described in the talk as Intel and ARM with the major required devices. Fewer devices mean less initialization work, fewer boot paths and less runtime state. A microVM can run a substantial Linux workload: it is the VMM that is small.

Arrakis's runtime choice starts with multitenancy. Different customers may run generated code on the same server, and one customer's workload must not gain host privileges and read another's data. MicroVMs also offer a convenient checkpoint primitive: guest memory is a bounded body of state the VMM can save and restore. Bhardwaj contrasts this with the difficulty of capturing a container's running state, including its dependence on the shared host kernel.

The available monitors have related implementation histories, but different priorities. Bhardwaj describes Firecracker and Cloud Hypervisor as crosvm forks; more precisely, Cloud Hypervisor documents code derived from both crosvm and Firecracker, alongside shared Rust VMM components.

Bhardwaj credits Firecracker with a more developed REST API and stronger jailing. He chose Cloud Hypervisor because, at the time of selection, it offered the snapshot and hardware capabilities he wanted, including runtime RAM hotplug described as PCI-device-based addition or removal. Participation from multiple companies also mattered to him. These are his selection criteria, rather than a measured ranking of the projects.

gVisor supplies another design point. Bhardwaj presents it as an intermediate option and says GPU access is easier with gVisor or containers than with microVMs. Its mechanism is more specific than a hardened conventional container: the Sentry implements application system calls and restricts the interface exposed to the host. Relative security depends on the implementation and attack surface, not simply whether hardware virtualization is present. Arrakis nevertheless selects Cloud Hypervisor, so the architecture now has a concrete VMM process running guest execution threads through /dev/kvm.

A VM boundary protects the host, but code can still damage its own guest filesystem. Deleting essential files may make a sandbox unusable. Arrakis separates the filesystem into a shared, read-only root image and a private read/write layer for each sandbox. New files and modifications belong to that sandbox's writable layer. A filesystem checkpoint therefore needs to preserve the writable layer, without duplicating the shared immutable base.

During early boot, the guest's init.sh sets up OverlayFS before handing off to the normal init process. Applications then see an ordinary root mount, with the layering hidden beneath it. The essential mount operation has this form, assuming the base and writable disks are already mounted at the indicated paths:

mkdir -p /state/upper /state/work /merged
mount -t overlay overlay \
  -o lowerdir=/base,upperdir=/state/upper,workdir=/state/work \
  /merged

Here /base supplies the lower, read-only tree; /state/upper stores private changes; and /state/work is OverlayFS's work directory on the same filesystem as the upper directory. Protecting the base does not make the merged guest view indestructible: whiteouts can hide lower-layer files without modifying the base image. The architecture preserves the reusable image while containing each sandbox's filesystem changes.

A sandbox needs network access to call APIs and other tools, and its applications need a route back to users. Arrakis creates a unique TAP device for each sandbox and connects those virtual interfaces to a Linux bridge on the host. Port forwarding then maps host-side service ports to the code execution or VNC server inside a guest. The guest network interface, host bridge and forwarding policy are separate pieces of that path.

The networking code first creates the bridge, brings it up and installs firewall rules governing traffic between host and guest. A separate function invokes iptables from Go to configure destination NAT. The central operation can be expressed as:

package networking

import (
    "os/exec"
    "strconv"
)

func forwardTCP(hostPort int, guestIP string, guestPort int) error {
    destination := guestIP + ":" + strconv.Itoa(guestPort)
    cmd := exec.Command(
        "iptables", "-t", "nat", "-A", "PREROUTING",
        "-p", "tcp", "--dport", strconv.Itoa(hostPort),
        "-j", "DNAT", "--to-destination", destination,
    )
    return cmd.Run()
}

DNAT rewrites the destination to the guest's address and port. This rule is one part of the surrounding bridge, routing and firewall setup, not a replacement for it. With the complete path installed, a VNC client on a laptop can reach the desktop inside the microVM.

Docker tooling customizes the filesystem that will run inside the VM. The demonstrated Dockerfile starts from Ubuntu 22.04 and installs standard tools, Chrome, Node.js, npm and Python. Chrome starts through systemd. Editing that Dockerfile changes the packages available to the agent without requiring it to install everything at runtime; using Docker for image construction does not change the microVM execution boundary.

Creating the VM brings the previous components together:

1. Select the root filesystem and the sandbox's writable overlay disk.
2. Allocate vCPUs, implemented as host threads, and assign guest memory from the host's available capacity.
3. Configure the TAP device and port forwarding.
4. Configure vsock for host–guest communication.
5. Spawn the VMM process and call its create-VM API with the assembled configuration.

The REST server is orchestrating devices and resources here; the VMM is responsible for running the guest.

Inside that guest, the code execution server exposes file upload, file download and command execution. A command request produces JSON containing output or an error. The files interface gives the agent a way to move application code and other data into and out of its environment. Bhardwaj's confidence in exposing such a powerful service depends on it living behind the guest VM boundary; running the same command server directly on the host would have a very different risk profile.

Chrome and the forwarded VNC server complete the interactive environment. The agent can run an application through the command API, while a user or computer-use client accesses its GUI inside the same sandbox.

A request such as “make a Google News-like app” is large and vague enough that an agent may fail partway through. Decomposing it into small steps helps, but a late failure in a long execution graph can still waste substantial work. A checkpoint lets the agent return to the last good environment, revise its plan and continue. Bhardwaj extends that idea to exploring alternative execution paths in parallel.

The state to preserve includes guest memory and the writable filesystem layer. Files created by the agent, running processes and open GUI windows are all part of the intended restored environment. Bhardwaj compares the continuation experience to closing and reopening a laptop lid: the useful property is resuming the machine's state, rather than merely recovering source files.

The execution-tree illustration returns to a last known good checkpoint and tries another path. Concurrent branching requires additional care: the current Arrakis README says same-host restoration reuses the original VM's IP, so the original must be stopped or destroyed first. The illustrated parallel exploration is therefore a broader execution model, not evidence of unrestricted concurrent cloning. In the demonstrated implementation, the filesystem is ext4; Btrfs is being explored for native incremental snapshots.

The conceptual checkpoint procedure is:

1. Pause the VM through the VMM API.
2. Snapshot guest memory.
3. Separately persist the writable overlay disk.
4. Resume the VM so the workload continues.

The code walkthrough orders the two persistence operations differently: it pauses, arranges for resume before the function exits, copies the stateful disk and then calls the VMM snapshot API. The important coordination is that both memory and writable disk state are captured while the VM is paused, and resume is arranged so the operation does not simply leave the sandbox suspended.

The Python entry point is py-arrakis:

pip install py-arrakis

Arrakis runs on your own infrastructure; the client supplies that server's IP address to the sandbox manager. Listing the existing VMs returns metadata including their addresses and exposed ports.

The demonstrated lifecycle is straightforward: start a sandbox, execute a command and inspect the output or error JSON key. Create a named snapshot when the environment reaches a useful state, then destroy the VM when it is no longer needed. Later, restore it by supplying the VM name and snapshot ID. The client interface packages the coordinated virtualization, storage and networking operations into a small set of lifecycle actions.

The final demonstration connects Claude Desktop to Arrakis through its MCP server and asks for a Google Docs clone with collaboration. Claude creates a sandbox and sends commands into it. The point is to give the model a full Linux environment and let it use familiar development tools, with little repeated prompting or additional agent-framework machinery.

Once the collaborative editor is running, Bhardwaj creates a snapshot and asks for dark mode. Claude adds the feature, and Bhardwaj reports that collaboration still works. The visible CollabDocs result shows two browser windows, one dark and one light, displaying the same document with greetings from two users.

He then changes his mind and restores the earlier checkpoint without dark mode. This rollback follows a working feature addition, not a failed implementation. Snapshotting makes a change reversible even when the reason to undo it is simply a changed preference.

The demo also ties networking back to the product experience. Bhardwaj emphasizes that the generated application supports people editing together through a network-backed service, rather than only presenting a client-side imitation of collaboration. The sandbox supplies the execution and connectivity needed to build an end-to-end application, and the checkpoint supplies a way to return to an earlier running version.

The remaining work targets the cost of using this environment repeatedly. Boot below one second remains a goal. Moving to Btrfs is intended to make persistence and incremental snapshots first-class capabilities. Higher sandbox density requires dynamic resource management, especially memory ballooning and runtime memory hotplug or removal. These mechanisms let the host adjust allocations as workloads change, helping pack more sandboxes onto a server without treating every guest's initial memory reservation as permanent.