MicroVM Internals & Isolation

Codex cloud execution runs each task in a microVM — a lightweight virtual machine that boots in milliseconds and provides full OS-level isolation. Unlike container-based isolation (Docker), microVMs use hardware virtualization (KVM/Firecracker) to create a true security boundary. A compromised process inside the microVM cannot escape to the host, cannot access other microVMs, and cannot persist after the session ends. Every session starts from a clean image with only the project files and declared dependencies.

The microVM lifecycle is deterministic: boot from base image, mount project files, install dependencies, execute tasks, capture outputs, destroy. There is no state persistence between sessions unless you explicitly configure it. This immutability is a security feature — it means every session starts with a known-good state, and any modifications (installed packages, created files, changed configs) are discarded when the session ends. Side effects cannot accumulate across sessions.

Local Codex uses a different isolation mechanism. On macOS, it uses Apple's Seatbelt (sandbox-exec) profiles. On Linux, it uses Bubblewrap (bwrap) with namespace isolation. Both restrict filesystem writes, network access, and process capabilities — but they are not as strong as microVM isolation. A determined attacker with code execution inside a local sandbox has more escape vectors than inside a microVM. This is why cloud execution is recommended for high-security workloads.

# Codex isolation layers (strongest to weakest)

1. Cloud microVM (Firecracker)
   - Hardware virtualization boundary
   - Ephemeral: destroyed after session
   - Network: fully controlled, default deny
   - Filesystem: copy-on-write from base image
   - Escape difficulty: requires hypervisor exploit

2. Local sandbox — Linux (Bubblewrap)
   - Namespace isolation (mount, PID, network)
   - Filesystem: bind-mount project dir read-write
   - Network: controlled via namespace
   - Escape difficulty: requires kernel exploit or misconfigured namespace

3. Local sandbox — macOS (Seatbelt)
   - Profile-based restrictions
   - Filesystem: path-based allow/deny
   - Network: profile-controlled
   - Escape difficulty: profile bypass or entitled process

4. No sandbox
   - Full user permissions
   - No isolation whatsoever
   - Use only in disposable environments (CI containers)