CDX-301d · Module 1

The Firecracker Isolation Model

4 min read

Codex Cloud sandboxes run on Firecracker — the same microVM technology that powers AWS Lambda and Fargate. Each task gets a dedicated virtual machine with its own kernel, a minimal device model, and a stripped-down userspace. Firecracker boots a VM in under 125 milliseconds, uses roughly 5 MB of memory overhead per instance, and enforces hardware-level isolation through KVM. This is not container isolation — there is no shared kernel, no shared namespaces, no escape path through /proc or /sys.

The Firecracker model trades flexibility for security and speed. Each microVM has a fixed number of vCPUs, a fixed memory allocation, and a read-only root filesystem layered with a writable overlay. The overlay captures all file modifications during task execution. When the task completes, the overlay is extracted as the diff, and the entire VM — kernel, memory, overlay — is destroyed. There is no garbage collection, no cleanup step, no residual state. Destruction is instantaneous because the hypervisor simply reclaims the memory pages.

Understanding the Firecracker boundary matters for task design. Your code runs inside a full Linux kernel with standard syscalls, but the virtual hardware is minimal: no GPU by default, no USB, no display. The network device is a TAP interface controlled by the host. The block device is a virtio disk backed by a sparse file. Every resource the VM consumes is metered and capped by the hypervisor — there is no way for a guest process to exceed its allocation.

Do This

  • Design tasks assuming a minimal Linux environment — standard syscalls, no exotic hardware
  • Keep task working sets small enough to fit in the allocated memory without swap pressure
  • Use the ephemeral nature of microVMs as a feature — no cleanup code needed

Avoid This

  • Assume the sandbox behaves like a Docker container — the isolation model is fundamentally different
  • Try to persist state between tasks by writing to non-project directories — the VM is destroyed
  • Depend on GPU availability unless explicitly provisioned in the task configuration