What is an agent sandbox? Claude Code, Codex, Cursor and Grok

Oct 31, 2026

An agent sandbox limits which files and hosts a coding agent's commands can reach. How the boundary works in Claude Code, Codex, Cursor and Grok Build.

~~~

A sandbox is an operating-system boundary around the commands a coding agent runs. You decide which directories those commands can write, and whether they can open network connections. Permission modes decide whether a command runs at all. The sandbox decides what it can touch if it does.

How a sandbox works

The agent asks to run a command. If your permissions block it, it stops. If they allow it, the command starts inside the sandbox, and so do the processes it spawns. A write outside the allowed directories fails. A connection to a host you didn’t allow fails, or waits for approval, depending on the tool.

The sandbox is not the whole agent. File-editing tools, MCP servers, and hooks may run outside it. A VM or a container around the entire process is a wider boundary than a sandbox around the shell.

The sandbox in each tool

	Claude Code	Codex	Cursor	Grok Build
Default	Off	On, `workspace-write`	No OS sandbox documented for local commands	Off
Turn it on	`/sandbox`, or `sandbox.enabled`	It is already on unless you pick Full access	Not documented	`grok --sandbox workspace`
Writes	Working directory, a temp directory, and directories you add	The workspace, plus writable roots	Not documented	Depends on the profile
Network	Proxy, allowlist starts empty	Off unless you enable it	Default tools are not a general HTTP client	Blocked on Linux for `read-only` and `strict`
Enforcement	Seatbelt on macOS, bubblewrap on Linux	Seatbelt on macOS, bubblewrap on Linux	Not documented	Seatbelt on macOS, Landlock on Linux

Claude Code

The Bash sandbox is off by default. Turn it on with /sandbox, or set sandbox.enabled to true in ~/.claude/settings.json. It wraps Bash, PowerShell, and Monitor commands, and the processes they start. It does not wrap Claude’s file tools, MCP servers, or hooks.

On macOS it uses Seatbelt. On Linux and WSL2 it needs bubblewrap and socat. Native Windows runs commands unsandboxed. Use WSL2 if you want the sandbox there.

By default a sandboxed command can write the working directory, a per-user temp directory, and directories you added. It can read most of the machine, including ~/.ssh and ~/.aws/credentials, until you deny those reads. Network connections go through a proxy on your machine. The allowed-domain list starts empty. The first new domain prompts for approval.

excludedCommands run outside the sandbox. Claude can also ask to retry a failed command unsandboxed, which allowUnsandboxedCommands controls. A command you type yourself at the ! prompt usually runs unsandboxed too.

If the sandbox cannot start, Claude Code runs commands without it unless you set sandbox.failIfUnavailable to true.

See Claude Code sandboxing.

OpenAI Codex

On the ChatGPT desktop app, the Codex CLI, and the IDE extension, local commands run sandboxed by default. macOS uses Seatbelt. Linux and WSL2 use bubblewrap, and Codex warns at startup if bwrap is missing. Windows uses a native sandbox in PowerShell, and the Linux implementation under WSL2.

The common modes are read-only, workspace-write, and danger-full-access. workspace-write is the default low-friction mode. The agent can read files, edit inside the workspace, and run routine commands there. Network access stays off unless you set sandbox_workspace_write.network_access. read-only can inspect files and cannot edit or run commands without approval. danger-full-access removes the filesystem and network boundaries.

Pair the mode with an approval policy. on-request works inside the sandbox and asks when it needs to leave. never does not ask. Full access, in the sandbox docs, means danger-full-access and approval_policy = "never" together.

Writable roots extend the directories Codex can modify without dropping the sandbox. Rules allow, prompt, or forbid command prefixes outside the sandbox, which is the narrower exception.

See Codex sandboxing.

Cursor

Cursor’s agent security page doesn’t describe an OS sandbox around local terminal commands. It describes approvals. Terminal commands need your approval by default. Run Modes, from an allowlist up to the Auto-review classifier, let trusted calls run without prompting. The page says those modes are best-effort guardrails, not a hard security boundary.

Workspace file edits are separate from the terminal. Agents can modify workspace files without approval, except configuration files. With default settings, Cursor’s own tools don’t make arbitrary network requests.

The CLI docs also say Cursor has full write access in non-interactive mode. That is a wider grant than the interactive approval default.

See Cursor agent security and Using Agent in the CLI.

Grok Build

The sandbox is off by default. It limits what the agent process and its children can read, write, and reach on the network, using Landlock on Linux and Seatbelt on macOS.

The built-in profiles are off, workspace, devbox, read-only, and strict. workspace can write the working directory, ~/.grok/, and temp, and it can read everywhere. Child network stays allowed. read-only writes only ~/.grok/ and temp, and blocks child network. strict also limits reads to the working directory and system paths. devbox is for cloud devbox environments.

Child-network limits are enforced on Linux only. On macOS they are a no-op for read-only and strict. ~/.grok/ stays writable so sessions can be saved. Built-in profiles don’t permanently protect paths such as ~/.ssh. A custom deny list does.

Turn a profile on with grok --sandbox workspace, with GROK_SANDBOX, or with profile under [sandbox] in ~/.grok/config.toml. Custom profiles live in ~/.grok/sandbox.toml or .grok/sandbox.toml. A managed requirements.toml can override the CLI flag.

See Grok Build sandbox.

Details checked against each vendor’s documentation in October 2026.

A real example

You want Codex to edit a blog repo and run its tests, and you don’t want it calling the network or writing outside the repo. This is the lower-risk local preset from the sandbox docs, in ~/.codex/config.toml:

sandbox_mode = "workspace-write"
approval_policy = "on-request"

Leave sandbox_workspace_write.network_access unset. The default for this mode is network off. Codex can change files in the repo and run npm test. It asks before it reaches outside the workspace or opens a connection.

The Grok Build equivalent for a repo you don’t trust yet is a named profile:

grok --sandbox read-only

That profile blocks child network on Linux. On macOS the sandbox page says the child-network limit is a no-op, so don’t treat it as a network wall there. Claude Code’s switch is /sandbox, then enable it for every project with sandbox.enabled in ~/.claude/settings.json.

When to turn it on

Turn it on when the agent runs commands you aren’t watching, or when it reads untrusted content. A cloned repo, a page fetch, and a package install are the usual reasons. Claude Code’s security page pairs that situation with a VM when the agent talks to external services.

Codex already sandboxes local commands. The decision there is whether to leave the default in place. Drop to read-only for a review that should not edit. Move to Full access only when you actually want no filesystem and no network boundary, ideally inside a machine you can throw away.

Skip a tighter profile when it blocks the command the task needs, and you would rather approve that command than widen the sandbox for the whole session. Codex rules and Claude Code’s domain prompt are the narrower exceptions.

Pitfalls

Claude Code’s sandbox covers the shell. A file tool can still write a file the sandbox would have blocked, and a hook runs as you. If a command fails inside the sandbox, Claude may ask to rerun it outside. Decline that when the failure is the boundary doing its job. If sandbox.failIfUnavailable is left off, a missing bubblewrap means the commands run with no sandbox and no extra error.

Codex Full access is two keys, not one. danger-full-access removes the boundary. approval_policy = "never" also removes the question. Either one alone is a different setting.

Grok’s read-only and strict profiles don’t block child network on macOS. They also keep ~/.grok/ writable, and they don’t lock ~/.ssh unless you add a deny. In-process network, the model API and web tools, is not what the child-network setting blocks.

Cursor’s approvals are not a sandbox. An allowlist that auto-runs a terminal command is the best-effort control the security page describes. Non-interactive mode has full write access. A cloud agent moves the work to another machine, which is a different boundary from a local sandbox.

A sandbox also doesn’t stop the agent from following hostile text. It stops some of the commands that text asks for. The prompt injection entry is the other half.

Things I let coding agents do unattended, and things I never do pairs a read-only Codex sandbox with the tasks that can run while you are away.
Vercel Sandbox tutorial is a separate microVM for code you don’t trust, which is a different product from the Codex and Claude Code sandboxes.
How Cloudflare Computer runs code for AI agents is another isolated place to run agent code, with its own filesystem and network story.
How to let coding agents test Mac apps in a VM puts the whole agent session’s clicks on a virtual machine, and VM Peek is my Mac app for watching what those agents do in there.

Permission modes: Permission modes decide what a coding agent can do without asking. The modes in Claude Code, Codex, Cursor and Grok Build, and what YOLO mode really skips.
Prompt injection: Prompt injection is instructions hidden in text a coding agent reads. How Claude Code, Codex, Cursor and Grok Build limit what that text can make the agent do.
Cloud agents: Cloud agents run a coding task on a remote machine instead of your laptop. How Claude Code, Codex, Cursor and Grok Bot start one, and what they cannot see.

All AI glossary entries →

Follow @flaviocopes

Want me to talk about your product? You can sponsor this site.