Sandboxing coding agents: what the built-in sandboxes do and don't cover

Coding agents run shell commands on developers' computers: they install packages, run tests and call build scripts. Any of those commands can come from text the agent read, such as a README, an issue or a dependency's install script. The main coding tools now ship operating-system sandboxes to limit what those commands can reach. This article looks at what the sandboxes in Claude Code and OpenAI Codex do, what still runs outside them, and which settings an organisation should enforce.

The context: two sandboxes, similar ideas

Both tools use the operating system's own isolation rather than containers: Seatbelt on macOS and bubblewrap on Linux. Codex adds a native Windows sandbox.

The Codex sandboxing documentation describes three modes: read-only, workspace-write, which is the default and lets the agent write inside the working folder, and danger-full-access, which removes the restrictions. Network access is a separate setting.

The Claude Code sandboxing documentation describes a sandbox for the Bash tool that limits which files commands can write and which hosts they can reach. Network traffic goes through a proxy that allows only listed domains, and the list starts empty. The sandbox is off by default: administrators or developers have to turn it on.

What the sandboxes cover

• File writes. Commands can write only in the working folder and other allowed paths. A malicious install script can't edit shell start-up files or other projects.
• Network. Commands can reach only allowed hosts. An exfiltration attempt to an unknown domain fails, or with Claude Code prompts the user.
• Child processes. Restrictions apply to everything a command starts, not just the command itself, because they are enforced by the operating system.

What they don't cover

This is where the documentation is most useful, because it is explicit.

• Reads. Claude Code's sandbox allows reading most of the file system by default, including folders like ~/.ssh, unless you add deny rules. A command that can read a key and reach an allowed host can still leak it.
• Other tools. In Claude Code, the sandbox applies to Bash commands. The documentation notes that the built-in file tools, MCP servers and hooks run outside it, under the separate permission system.
• Escape hatches. Claude Code can retry a failed command outside the sandbox, with the user's permission. The allowUnsandboxedCommands: false setting removes that option. failIfUnavailable stops the tool from running unsandboxed where the sandbox can't start.
• Allowed hosts. An allowed domain is allowed for everything. Allowing a package registry also allows anything published to it.

Analysis: what to make of it

A sandbox is a real improvement over trusting the model. Prompt injection can't be fully prevented by instructions to the model. An operating-system boundary keeps working whatever the model was persuaded to do.

Defaults decide most of the outcome. A sandbox that is off by default, or that a developer can switch off when it gets in the way, protects only the people who chose it. Organisations that want this protection need to set it centrally.

Network allowlists are the hardest part. Too narrow and builds fail; too wide and they stop little. Most teams will end up allowing their package registries, source host and model provider. That is still far better than open access, but it is not a closed box.

Reads deserve as much thought as writes. Most damaging attacks on developer computers steal credentials rather than change files. Deny rules for key and token folders are worth adding even where the default allows reads.

What it means for engineering and security leaders

Treat agent sandboxing like other endpoint controls: decide a baseline, enforce it through managed settings, and accept exceptions only with a reason. Check which tools your developers actually use, because each has its own model and its own defaults.

Remember the parts the sandbox doesn't reach. MCP servers, plug-ins and hooks need their own controls: an inventory, an approved list, and logging of what they do.

Practical takeaways for this week

• Turn on the sandbox in the coding tools you use, through managed settings rather than individual configuration.
• In Claude Code, set allowUnsandboxedCommands: false and failIfUnavailable in managed settings.
• Add read-deny rules for credential folders such as ~/.ssh, cloud credential files and token stores.
• Start network allowlists with your package registries, source host and model provider, and review additions.
• Keep Codex in workspace-write or read-only mode; treat danger-full-access as an exception.
• List the MCP servers and hooks your teams run, since they sit outside the sandbox.

Where SpanDock fits

On the Enterprise plan, SpanDock guardrails check the prompt and every tool call in Claude Code, Codex and Gemini CLI before it runs, including MCP tool calls through the gateway, and can block, warn, ask the person to confirm, or redact; every match is recorded. Also on Enterprise, process inventory shows which AI tools run on each computer, including the ones that send no telemetry.