The VaultHow Every Command Runs in a Sandbox

Why Sandboxing Matters

Imagine this scenario. You ask an AI coding agent to clean up some temp files. The agent, confident in its interpretation, generates a command:

# The AI's "helpful" suggestion
rm -rf /

Without a sandbox, that command executes directly on your machine. Your files, your OS, your entire system — gone. With a sandbox, the command runs inside a contained environment. It can only see what you allow it to see. It can only touch what you explicitly permit.

The ExecPolicy DSL

Before any command even reaches the sandbox, it passes through the ExecPolicy — a domain-specific language that defines rules for what commands are allowed, which need human approval, and which are outright forbidden.

Three rule types form the vocabulary:

type ExecPolicy = {
  prefix_rule: {         // Matches command prefixes
    prefix: "npm ",
    decision: "allowed"
  },
  exact_rule: {          // Matches exact commands
    command: "rm -rf /",
    decision: "forbidden"
  },
  network_rule: {        // Controls network access
    host: "registry.npmjs.org",
    decision: "allowed"
  }
}

Each rule maps a pattern to one of three decisions: allowed, prompt, or forbidden. The policy engine evaluates them top-to-bottom, first match wins. Here's what a real policy might look like:

The Three-Tier Approval Flow

Every command the AI generates passes through a three-stage gate before it can execute. This is not a single check — it's a pipeline, and each stage can halt the command entirely.

If the ExecPolicy says allowed, the command proceeds directly to sandbox execution. If it says prompt, the user sees a confirmation dialog with the exact command and can approve or reject. If it says forbidden, the command is silently dropped — the AI receives an error and must try a different approach.

Linux Sandboxing: Three-Layer Cake

On Linux, Codex CLI builds the strongest sandbox using three independent, overlapping security mechanisms. Each layer defends against a different class of escape. Click each layer to explore.

macOS Sandboxing: Seatbelt

On macOS, Linux namespaces don't exist. Instead, Codex CLI leverages Apple's Seatbelt framework — the same sandbox technology that powers the Mac App Store's security model. Seatbelt uses capability-based profiles written in a Lisp-like syntax.

;; Generated sandbox profile for Codex CLI
(version 1)
(deny default)          ;; Deny everything by default

(allow process-exec)     ;; Allow executing the command
(allow file-read*
  (subpath "/usr/lib")
  (subpath "/usr/bin")
  (subpath "/System"))

(allow file-read* file-write*
  (subpath "$PROJECT_DIR"))

(deny network*)          ;; No network unless allow-listed
(allow network-outbound
  (remote tcp "registry.npmjs.org:443"))

The key insight: these profiles are generated on the fly. When the ExecPolicy allows network access to specific hosts, the Seatbelt profile generator dynamically adds those hosts. The profile is written to a temp file and passed to sandbox-exec at spawn time.

Windows Sandboxing

Windows takes a fundamentally different approach. Rather than namespaces or profiles, it relies on the combination of three native security mechanisms working in concert.

Platform Comparison

Each platform reaches the same security goal — containment — through entirely different mechanisms. Here's a side-by-side view.

Network Sandboxing

Network access is the most dangerous capability to grant. A compromised process with network access can exfiltrate data, download malware, or establish reverse shells. Codex CLI treats network access with the same rigor as filesystem access, using platform-specific mechanisms.

Cross-Platform Network Control

• Linux: Network namespace isolation via --unshare-net. When network is needed, iptables rules whitelist specific hosts/ports.
• macOS: Seatbelt network-outbound rules in the generated profile. Deny-default for all network, explicit allows per host.
• Windows: Windows Firewall rules scoped to the process. netsh commands configure per-process outbound rules.

The Vault in Action

Let's trace a real command — npm install express — through the entire vault. Click "Run Trace" to watch the command flow through every security layer.

The entire flow is invisible to the user in normal operation. When everything is allowed, it feels like running commands directly. The vault's power is in what it prevents — the commands that never escape, the network calls that never connect, the files that remain untouched.

Key Takeaways