Sandboxing Is Starting to Look Like a Runtime Layer for AI Coding Agents

For a while, sandboxing in agent tools felt like a settings-page checkbox — useful, important, but still bolted on. That is not what some of the code now looks like.

Across OpenClaw, Gemini CLI, and Codex, the trust boundary is becoming a more explicit product surface. The implementations differ. But the pressure is the same: if an agent can read files, rewrite code, spawn helpers, and run shell commands, execution isolation cannot stay vague.

The shift is simple: sandboxing is moving closer to runtime design, not just safety copy.

OpenClaw turns the sandbox into backend architecture

OpenClaw offers the clearest example of sandboxing expanding into system design. In src/agents/sandbox/backend.ts, the runtime now defines a registry for sandbox backends with factory and manager interfaces, plus core registration for both docker and ssh. That is a real step beyond “run everything in one container.” The sandbox becomes something the platform can swap, inspect, and manage.

The same pattern shows up in src/agents/sandbox/types.ts. SandboxConfig now carries a backend ID, scope, workspace access mode, tool policy, browser settings, pruning policy, Docker config, and SSH settings. In plain terms: sandboxing is no longer one isolation trick. It is becoming a runtime contract.

That matters because the runtime targets are widening. The new src/agents/sandbox/ssh-backend.ts creates session-scoped remote runtimes, uploads local workspace state into the remote environment, builds SSH-backed exec specs, and exposes a remote filesystem bridge. OpenClaw is making room for the idea that the “safe” place to run an agent might be a container — or another machine.

And the hardening is not cosmetic. In src/agents/sandbox/fs-bridge.ts and src/agents/sandbox/remote-fs-bridge.ts, file writes, removes, and renames go through pinned mutation plans, path-safety checks, canonical path resolution, and hardlink defenses. The notable part is not just process isolation at launch. It is carrying that caution into file operations too.

Put simply: OpenClaw is treating the sandbox as infrastructure. Backends are pluggable, scope is explicit, and the filesystem bridge is handled like an attack surface, not a convenience wrapper.

Gemini CLI turns sandboxing into per-execution policy

Gemini CLI is moving in a similar direction from a different starting point. Rather than foregrounding multiple backends, it is turning sandboxing into a composable execution policy.

In packages/core/src/services/sandboxManager.ts, Gemini defines an ExecutionPolicy with fields including allowedPaths, forbiddenPaths, networkAccess, and environment sanitization rules. That policy travels on each SandboxRequest. The practical change is important: the sandbox is not just a global mode anymore. It can be shaped per execution.

The platform-specific details make that concrete. In packages/core/src/sandbox/macos/MacOsSandboxManager.ts, Gemini wraps commands with /usr/bin/sandbox-exec. The companion baseProfile.ts starts from (deny default) and then allowlists system paths, temporary directories, PTY support, workspace access, and optional network behavior through Seatbelt rules. That is not a generic safety wrapper. It is direct use of the native macOS sandbox model.

Linux gets similarly explicit. In packages/core/src/sandbox/linux/LinuxSandboxManager.ts, Gemini builds a bwrap command that unshares namespaces, creates fresh /dev, /proc, and /tmp, bind-mounts the workspace and approved paths, and adds a seccomp filter that blocks ptrace. That turns “sandboxing” from a fuzzy promise into a stack of specific OS-level choices.

The broader pattern is clear: Gemini is threading execution policy down to the call site. Allowed paths, denied paths, network access, and env scrubbing are becoming part of how each command is launched.

Codex shows that trust has to persist across agent boundaries

Codex is a useful contrast because the signal here is not new sandbox backends. It is continuity of execution policy. That is a narrower claim, but still an important one.

In codex-rs/core/src/exec_policy.rs, Codex includes child_uses_parent_exec_policy(...), which checks whether a child thread should inherit the parent’s execution-policy context. The same module also separates rejection paths for sandbox approvals and rule approvals, suggesting more granular handling of what gets surfaced to the user and when.

That is different from OpenClaw’s backend work or Gemini’s OS-specific wrappers. But it addresses a real runtime problem they also face: once work fans out into subagents or threads, trust settings cannot remain local trivia. The approval and execution envelope has to travel with the work.

So even without the same backend story, Codex points in the same general direction: execution policy is becoming durable runtime state, not just a one-time choice.

Why this matters outside the repos

The product framing is drifting the same way. OpenAI’s Codex CLI page emphasizes that the tool can read, change, and run code locally while letting users choose approval modes. Gemini CLI’s public README highlights shell, file, and web tools, plus a fast preview/stable/nightly cadence — exactly the sort of shipping environment where runtime safeguards matter. Anthropic’s Claude Code docs likewise describe a tool that edits files, runs commands, and keeps shipping security fixes.

That context matters because the pressure is no longer academic. Terminal agents are becoming mainstream developer products, and mainstream products need a clearer answer to a basic question: where, exactly, is this thing allowed to execute?

The broader pattern: the next moat may be operational trust

We usually talk about coding agents as a race in model quality, reasoning depth, or interface polish. Those things matter. But the code this week suggests another battleground underneath them.

OpenClaw is making isolation pluggable across Docker and SSH while hardening the filesystem bridge. Gemini is turning sandboxing into an explicit per-request policy layer tied to native OS controls. Codex is making sure execution policy can survive delegation instead of disappearing when work moves to a child thread.

Different architectures, same pressure: users do not just need powerful automation. They need clear containment.

If this keeps accelerating, a coding agent will be judged not just by what it can do, but by how explicitly it constrains that power. The crisp takeaway from this week’s code is simple: in AI coding tools, trust boundaries are becoming part of the runtime story. Will developers start choosing agents as much for their containment model as for their raw intelligence? If you’re building one, now’s a good time to ask whether your trust model is really in the runtime — or still hiding in a checkbox.