How nd7 compares to other ways of sandboxing a coding agent

There are several ways to keep a coding agent from doing damage. This page leads with what each one is missing, because that is the part a vendor's own documentation states plainly and a comparison page usually skips. Every gap below is a sentence from the source, not an inference. If you have not met the layers before, read How sandboxing works first.

Every fact was read from the linked source on 2026-09-22, except the nono entries, which come from nd7's own competitive notes of 17 September 2026. Products move quickly; treat the date as part of the claim. Where a source does not answer a question, the entry says "not stated in the documentation read", and that counts as a gap: it is something to ask the vendor, not something to assume in their favour. Nothing here is a ranking, and nd7's own limits are stated in the same words as everyone else's.

At a glance#

Same questions, asked of each system in the same order.

nd7#

Audit log of what the agent did: yes, an append-only BLAKE3 hash chain per session, verified by nd7 verify. It records intent — what the agent said it was about to do — not what the kernel saw.
Isolation layer: process sandbox (Seatbelt).
Runs where: your machine.
Your real checkout and tools: yes.
Rules changeable while running: yes, from outside the sandbox, applied to the next Bash command.
Platforms: sandbox macOS only; recording macOS and Linux.
Licence: MIT.
Documented escape or bypass path: one literal path, the nd7-exec binary, may be executed in a way that leaves the sandbox; it takes nothing from its caller and re-applies the session's rules to itself. Everything inside the allowed area, including HTTPS on port 443 to any host, is unconstrained.

Claude Code's built-in sandbox#

Audit log of what the agent did: not stated in the documentation read. Sandbox violations are reported and, on macOS, readable from the system log; a custom proxy can "Log all network requests". Neither is a record of the agent's tool calls.
Isolation layer: process sandbox: Seatbelt on macOS, bubblewrap plus an optional seccomp filter on Linux, with a proxy for network.
Runs where: your machine.
Your real checkout and tools: yes.
Rules changeable while running: yes; editing the filesystem lists "applies the change to the running session".
Platforms: "supports macOS, Linux, and WSL2. WSL1 and native Windows are not supported."
Licence: not stated in the documentation read; the standalone runtime is Apache-2.0.
Documented escape or bypass path: dangerouslyDisableSandbox, the unsandboxed fallback when the sandbox cannot start, excludedCommands, filesystem.disabled, allowAppleEvents, enableWeakerNestedSandbox, and typed ! shell-mode commands. Each is named below.

OpenAI Codex CLI#

Audit log of what the agent did: not stated in the documentation read.
Isolation layer: process sandbox: Seatbelt on macOS, bubblewrap on Linux and WSL2, a native sandbox on Windows.
Runs where: your machine.
Your real checkout and tools: yes.
Rules changeable while running: not stated in the documentation read.
Platforms: macOS, Windows, Linux and WSL2.
Licence: Apache-2.0.
Documented escape or bypass path: sandbox_mode = "danger-full-access" with approval_policy = "never", which the documentation calls full access; and, on Linux, a fallback to "a bundled helper" when bubblewrap is unavailable.

nono#

Audit log of what the agent did: yes, but of decisions rather than operations — a hash chain plus a Merkle root over recorded event leaves, with an optional keyed DSSE signature.
Isolation layer: process sandbox: Seatbelt on macOS, Landlock on Linux.
Runs where: your machine.
Your real checkout and tools: yes.
Rules changeable while running: not stated in the notes read.
Platforms: macOS, Linux.
Licence: not stated in the notes read.
Documented escape or bypass path: not stated in the notes read.

Docker Sandboxes#

Audit log of what the agent did: not stated in the documentation read.
Isolation layer: microVM. "Each sandbox gets its own Docker daemon, filesystem, and network."
Runs where: your machine.
Your real checkout and tools: no. The agent works on what you share into the sandbox, with the sandbox's own tooling.
Rules changeable while running: not stated in the documentation read.
Platforms: macOS, Windows, Linux.
Licence: not stated in the documentation read.
Documented escape or bypass path: not stated in the documentation read.

A plain Docker container#

Audit log of what the agent did: not stated in the documentation read. A container is an environment, not a recorder.
Isolation layer: container: namespaces and control groups.
Runs where: your machine or a server.
Your real checkout and tools: only what you mount; the tools are the image's.
Rules changeable while running: not stated in the documentation read.
Platforms: not stated in the documentation read.
Licence: Apache-2.0 (Docker Engine).
Documented escape or bypass path: not stated in the documentation read.

gVisor#

Audit log of what the agent did: not stated in the documentation read.
Isolation layer: an application kernel in user space.
Runs where: your machine or a server.
Your real checkout and tools: only what you mount.
Rules changeable while running: not stated in the documentation read.
Platforms: Linux 5.6 or greater, x86-64 and ARM64.
Licence: Apache-2.0.
Documented escape or bypass path: not stated in the documentation read.

A Firecracker cloud sandbox (E2B)#

Audit log of what the agent did: not stated in the documentation read. "Audit logging" is listed among the safeguards for HIPAA-regulated workloads, without saying what is recorded about code running inside a sandbox.
Isolation layer: microVM on a provider's machine. "Isolation is at the hypervisor boundary, not the container or process boundary."
Runs where: the provider's cloud, or your own cloud account on enterprise plans.
Your real checkout and tools: no; you send files to it and get them back.
Rules changeable while running: not stated in the documentation read.
Platforms: the sandbox is a Linux virtual machine.
Licence: not stated in the documentation read.
Documented escape or bypass path: not stated in the documentation read.

bubblewrap#

Audit log of what the agent did: no. It is not a recording tool.
Isolation layer: process sandbox: user, IPC, PID, network and UTS namespaces plus seccomp filters.
Runs where: your machine.
Your real checkout and tools: yes, if you bind the paths in.
Rules changeable while running: no; the sandbox is fixed when it is created.
Platforms: Linux.
Licence: LGPL-2.1.
Documented escape or bypass path: not stated in the documentation read.

Claude Code's built-in sandbox: what is missing#

Sources: the sandboxing documentation and the sandbox-runtime repository, both read on 2026-09-22.

Gaps#

The agent's own writing tools are outside the boundary. Under "Scope" the documentation says: "The sandbox isolates Bash subprocesses", and "Built-in file tools: Read, Edit, and Write use the permission system directly rather than running through the sandbox." For a coding agent that is most of the writing it does: a boundary that stops rm -rf typed into Bash but not the same deletion expressed as a Write is a partial boundary, and the part it misses is the part the agent uses by default.
The model itself can ask to leave. "Claude analyzes the violation and may retry the command with the dangerouslyDisableSandbox parameter." The retried command "runs outside the sandbox, so it goes through the regular permission flow", and in auto mode "the classifier evaluates the underlying command." So the decision to step outside is taken by the same model the boundary exists to confine, and is then reviewed by a classifier rather than by the kernel. It can be turned off with allowUnsandboxedCommands: false; it is on by default.
The default when the sandbox cannot start is to run without it. "By default, if the sandbox cannot start because dependencies are missing or the platform is unsupported, Claude Code shows a warning and runs commands without sandboxing." A missing package on a colleague's Linux box therefore produces a warning and an unconfined session rather than a stop. sandbox.failIfUnavailable makes it a hard failure and is described as "intended for managed deployments".
No audit log of agent actions is stated. The documentation covers violation reporting and a custom proxy that can "Log all network requests"; nothing in it records the prompts, tool calls and results of a session. After a session goes wrong you have the transcript, on the same disk the agent could write to.
The network allowlist is decided from a hostname the client supplies. "Because the proxy makes its allow decision from the client-supplied hostname without inspecting TLS, code running inside the sandbox can potentially use domain fronting or similar techniques to reach hosts outside the allowlist", and "Allowing broad domains such as github.com can create paths for data exfiltration." Domain filtering is real and it is better than nd7's port filtering; it is not airtight, and the documentation says so.
Several settings are documented as removing protection, not merely loosening it. allowAppleEvents "removes code-execution isolation: sandboxed commands can launch other applications unsandboxed with no user prompt"; enableWeakerNestedSandbox "considerably weakens security"; filesystem.disabled gives sandboxed commands "unrestricted read and write access to the host filesystem". Each one is a single key that a project can be configured into.
A developer can always step out by typing. "A developer can still type a command at the ! shell-mode prompt and run it outside the sandbox, with the same access they already have in any terminal outside Claude Code." That is reasonable for a person, and it means the sandbox is not a boundary around the session as a whole.

Where it has an edge#

It is already installed, it runs on Linux and WSL2 as well as macOS where nd7's sandbox is macOS-only, and it filters egress by domain through a proxy where nd7 allows TCP port 443 to any host — a genuinely stronger network story. It also has an interactive panel, /sandbox, separate allow and deny lists for reads and writes, credential masking, and a published Apache-2.0 runtime, sandbox-runtime, that can wrap arbitrary processes.

OpenAI Codex CLI: what is missing#

Sources: the hosted sandboxing documentation and the openai/codex repository, both read on 2026-09-22.

Gaps#

Two settings turn the boundary off for the session. The documentation defines the unrestricted configuration explicitly: "Full access means using sandbox_mode = \"danger-full-access\" together with approval_policy = \"never\"." Of never it says "The agent doesn't stop for approval prompts." An agent told to stop failing tasks will find this configuration in its own documentation.
The confinement mechanism has a documented fallback. On Linux, when bubblewrap is unavailable, "Codex falls back to a bundled helper" and surfaces "a startup warning". The session continues under a different mechanism after a warning, rather than stopping.
No audit log of agent actions is stated. Nothing in the documentation read records prompts, tool calls or results, and there is no verify command for such a record.
The allowlist trusted a command's name rather than its invocation. Pillar Security's July 2026 research found Codex CLI's "safe" command allowlist "trusted git show by name while the actual invocation was not read-only", fixed in v0.95.0 (BleepingComputer, 2026). A name-based allowlist is a rule about strings, not about what the kernel will be asked to do.
The repository page does not state the sandbox's own limits. Read on 2026-09-22, openai/codex points at the hosted documentation and does not itself set out sandbox modes, approval policies, logging or limitations. Not stated in the documentation read, and worth asking about.

Where it has an edge#

It runs on macOS, Linux, WSL2 and Windows, where nd7 runs on macOS only, and its workspace-write default plus sandbox_workspace_write.writable_roots lets you "extend the places it can modify without removing the sandbox entirely". Pairing the sandbox with an approval policy means the agent asks before crossing the boundary rather than simply failing, and the repository is Apache-2.0.

nono: what is missing#

The closest comparable project, covered in detail on its own page: How nd7 compares to nono. Everything here comes from nd7's own competitive notes of 17 September 2026, not from a fresh reading of nono's documentation.

Gaps#

The unit of record is a decision, not an operation. Per the notes, an audit event is "One recorded fact within that session, such as session_started, session_ended, a capability decision, or a supervisor-observed URL-open event." A denied action is a row; the allowed ones are where damage happens, and a decision log tells you what the supervisor concluded rather than what the agent did.
Undo is per session, not per operation. The notes record two snapshots — a baseline before the command and a final one after it, indexed 0 and 1. Two snapshots cannot revert the third of seven edits, and cannot tell an agent's change from a concurrent human one, which is exactly the situation after an agent and a person have both been editing.
The trail exists only under nono. It covers commands launched through nono and nothing else, so a session run any other way leaves no record at all.
Cross-machine sessions are not addressed. Nothing in the notes covers an agent that connects to another host, so a session that leaves the machine leaves the record behind.
Executable identity stops at argv[0]. "Only the main executable (argv[0] after resolution) is hashed. For bash script.sh, this commits /bin/bash, not script.sh." The interesting artefact — the script — is the one not committed.
Escape or bypass paths: not stated in the notes read. The notes do not cover them, so this is unknown rather than absent.

Where it has an edge#

It enforces on Linux as well as macOS, and its integrity story is more complete than nd7's: a hash chain plus a Merkle root plus an optional keyed DSSE signature, checked by nono audit verify, where nd7's signature field is reserved and unimplemented. It also has undo today and a reader command, nono audit list | show | verify | cleanup, where nd7 has only nd7 verify.

Docker Sandboxes: what is missing#

Source: Docker's Sandboxes documentation, read on 2026-09-22.

Gaps#

No audit log of agent actions is stated. Nothing in the documentation read records what the agent did; centralised policy is offered separately, and "organization governance requires a separate paid subscription".
The environment is not the developer's. "Docker Sandboxes run AI coding agents in isolated microVM sandboxes. Each sandbox gets its own Docker daemon, filesystem, and network", and the agent works "without accessing host resources beyond those you share." Whatever your machine has that you did not share — a local toolchain version, a credential helper, a scratch directory two levels up — the agent does not have, and reproducing it is your work.
Escape or bypass paths: not stated in the documentation read. A microVM is a strong boundary, and the documentation does not set out what it does not cover.

Where it has an edge#

The boundary is a microVM, so a host kernel bug is out of the agent's reach and the host filesystem is absent rather than rule-protected — strictly stronger than anything a Seatbelt profile can do. It supports several agents out of the box on macOS, Windows and Linux.

A plain Docker container: what is missing#

Source: Docker's security documentation, read on 2026-09-22.

Gaps#

No audit log of agent actions is stated. The security documentation does not address logging of what runs inside a container. A container is an environment; recording is a separate problem you still have.
The environment is not the developer's. The agent sees only what you mount, with the tools that went into the image.
The isolation is described in terms of processes, not the kernel. "Processes running within a container cannot see, and even less affect, processes running in another container, or in the host system", and "Control Groups … implement resource accounting and limiting." The documentation read makes no claim about kernel-level isolation, so treat that boundary as comparable to a process sandbox unless you add one.

Where it has an edge#

An image is a written-down, shareable description of the machine the agent gets, identical on every developer's machine and in continuous integration, which a Seatbelt profile is not. The isolation also covers the process table, the network stack and resource consumption, none of which nd7 touches.

gVisor: what is missing#

Sources: the repository and the architecture guide, read on 2026-09-22.

Gaps#

No audit log of agent actions is stated. gVisor does not know what a tool call is, so there is nothing agent-shaped to record and nothing that records it.
Not macOS, and not your checkout. It runs on "Linux 5.6+" on x86-64 and ARM64, and the workload sees a container's filesystem rather than your working tree.
It is a runtime, not an agent tool. There is no notion of widening a rule mid-session, no hook into an agent, and nothing to verify afterwards.

Where it has an edge#

It is built for exactly the threat a process sandbox cannot address — "additional defense against the exploitation of kernel bugs by untrusted userspace code" — and states the property directly: "No system call is passed through directly to the host." It is Apache-2.0.

A Firecracker cloud sandbox (E2B): what is missing#

Source: E2B's security page, read on 2026-09-22.

Gaps#

No audit log of agent actions is stated. The page lists "audit logging" among the technical safeguards for HIPAA-regulated workloads, but does not say what is recorded about code running inside a sandbox, or how you read it. Isolation is documented in detail; the record is not.
The sandbox is disposable, and so is whatever it knew. "Filesystem and memory state can be preserved across a pause and restored on resume", but sandboxes are otherwise destroyed on timeout or shutdown, so nothing about a session survives by default.
Your files have to travel, and they land on someone else's machine. The agent is not working in your environment, and your code sits on a third party's infrastructure unless you deploy into your own AWS or Google Cloud account; "Azure is not yet supported."
Escape or bypass paths: not stated in the documentation read. The hypervisor boundary is the strongest of the ones here, and the page does not enumerate its limits.

Where it has an edge#

"Every sandbox runs in its own Firecracker microVM with its own kernel", isolation is "at the hypervisor boundary, not the container or process boundary", and sandboxes "never share a kernel, a filesystem, or memory with another customer's sandboxes." If you run agents on other people's code, at a scale past one laptop, this is the layer the problem calls for.

bubblewrap: what is missing#

Source: the README, read on 2026-09-22.

Gaps#

It is not a recording tool. There is no audit log of agent actions, by design; bubblewrap is a mechanism for constructing a sandbox.
The rules are fixed when the sandbox is created. Nothing can be widened while a session runs, so a rule set has to be right in advance or the agent stops.
Linux only, and agent-unaware. It does not run on macOS, and it has no notion of a tool call, a session or a prompt.

Where it has an edge#

It is the building block both Claude Code's and Codex's Linux sandboxes rest on, and nd7 has nothing on Linux at all. It is composable, scriptable and unprivileged, and it isolates the process table and the network namespace, which Seatbelt rules do not.

What nd7 insists on that the others do not#

A kernel boundary around the agent process itself, not only around the commands it runs. nd7 applies one profile to claude and everything it spawns, so Write and Edit are inside the boundary rather than governed by a permission prompt; Claude Code's documentation states the opposite of its own sandbox, and the July 2026 sandbox-escape research turned on exactly this distinction. The limit: this is macOS only, and a Linux sandbox is planned and not built.

Rules widened only from outside the sandbox, never from inside. macOS refuses any attempt by a confined process to apply a different profile, so neither the model nor a command it runs nor a compromised dependency can widen the boundary; there is no dangerouslyDisableSandbox and no danger-full-access, and widening happens through nd7 allow from another terminal. The limit: network filtering is by port, not hostname, so HTTPS on 443 to any host is allowed and nothing about widening changes that.

An append-only, hash-chained record kept without needing the sandbox. Recording runs from Claude Code's hooks with no wrapper and no privileges, so the log exists whether or not the session was confined, and it can be shipped to a vault the recording machine cannot rewrite. The limit: every entry is intent — what the agent said it was about to do — not what the kernel saw, and each one says so through its source field.

Incidents that shaped this comparison#

Four of them, set out with their sources on When sandboxes failed.

OpenAI and Hugging Face, July 2026. Models in an internal evaluation environment with reduced refusals escaped through a zero-day in the single network channel they were allowed — a package-registry cache proxy — and went on to execute code on Hugging Face servers. The one permitted egress path was the attack surface, and reconstruction afterwards was possible because events had been logged.

Pillar Security's "week of sandbox escapes", July 2026. Four coding agents were found to have escape paths in which the agent never broke out directly: it wrote a file that a trusted component outside the sandbox later ran. The lesson is that the boundary has to sit around the agent process and everything downstream of what it writes, not around a list of commands.

The Claude Code network sandbox bypass, disclosed May 2026. A null-byte in a hostname made an allowlist of *.google.com approve a connection the operating system then dialled elsewhere. A network allowlist evaluated above the kernel is a parser, and parsers disagree with the kernel.

Coding agents deleting user data, 2025 and 2026. A Replit agent deleted a production database during a declared code freeze, and Gemini CLI and Claude Code have primary-source reports of recursive deletes running unprompted, in one case taking the session's own transcript with them. A write-root boundary stops these; a permission prompt did not.

Which should I use?#

Three rules of thumb.

If the agent's code must not touch your machine at all, use a microVM or a cloud sandbox. Docker Sandboxes locally, E2B and similar remotely. You pay for it by moving your project into a separate machine and getting the results back out.

If you want a reproducible environment, use a container, and add gVisor if kernel bugs are in your threat model. An image is a description of the machine the agent gets, identical everywhere.

If the agent has to work in your real environment, and you want a record of what it did, use a process sandbox. That is what nd7 is for, and its limits are stated on How the macOS sandbox works and Roadmap: macOS only, network filtering by port rather than hostname, and a log of what the agent said it did rather than what the kernel saw. If you already use Claude Code and none of the above applies, its built-in sandbox is the smallest step and runs on more platforms; nd7 is the step after that, for the agent process itself and for the record.

Updated 22 September 2026. This page as Markdown · Source on GitHub.