Blog / coding agents
Best Sandboxed AI Coding Agents for Secure Local Development (2026)
Which coding agents sandbox their own commands, which leave it off by default, which rely on approvals, and how to sandbox any agent.
The best sandboxed coding agents for local development are Codex CLI, which sandboxes commands at the OS level by default, and Claude Code, which has the most configurable sandbox but leaves it off by default. Cursor sandboxes terminal commands in its default mode, and OpenHands runs in Docker by default. Gemini CLI and Kilo Code have optional sandboxes. Cline, OpenCode, Goose and Aider rely on approvals only.
One gap runs through almost all of them: none removes secrets from the agent's environment by default. A sandboxed command can usually still read your API keys. If that matters, run the agent inside a sandbox that keeps keys on the host, like Hotcell or Docker Sandboxes. Details below, checked against each tool's docs. Last reviewed October 2026.
At a glance
| Agent | Licence | Built-in sandbox | On by default | Network when sandboxed | Secrets hidden by default |
|---|---|---|---|---|---|
| Codex CLI | Apache-2.0 | OS sandbox: Seatbelt, bubblewrap, native Windows | Yes | Off in workspace-write |
No |
| Claude Code | Proprietary | OS sandbox: Seatbelt, bubblewrap; not native Windows | No | Proxy with an empty allowlist | No (opt-in deny or mask) |
| Cursor | Proprietary | OS sandbox for terminal commands | Yes, in Auto-review mode where supported | Blocked, plus default registries | Not documented |
| OpenHands | MIT | Docker container | Yes | No limits documented | Not documented |
| Gemini CLI | Apache-2.0 | Seatbelt, Docker/Podman, gVisor, Windows | No | Depends on profile | No (opt-in redaction) |
| Kilo Code | MIT | OS sandbox: Seatbelt, bubblewrap | No | Deny by default, allowlist proxy | No |
| Autopilot | MIT | Subagents in Hotcell sandboxes; main agent uses approvals | Subagents only | Hotcell gateway | Subagents: yes, tokens only |
| Cline | Apache-2.0 | None (approvals) | n/a | n/a | No |
| OpenCode | MIT | None (permissions) | n/a | n/a | No (.env reads denied) |
| Goose | Apache-2.0 | None currently (approvals) | n/a | n/a | No |
| Aider | Apache-2.0 | None (confirm each command) | n/a | n/a | No |
Sandboxed by default
Codex CLI is the strongest default. Its sandbox is on from the start: Seatbelt on macOS, bubblewrap with seccomp on Linux and WSL2, and a native sandbox on Windows. In workspace-write mode the agent can only write inside the workspace, paths like .git and .codex stay read-only, and network access is off until you turn it on. The gap is secrets: by default, environment variables with KEY, SECRET or TOKEN in the name are passed to commands, so set shell_environment_policy to exclude them. Our Codex sandbox guide covers setup.
Cursor sandboxes agent terminal commands in its recommended Auto-review mode when the OS supports it: Seatbelt on macOS, Landlock and seccomp on Linux 6.2+. Network is blocked except package registries and whatever you allow in sandbox.json. Reads outside the workspace are allowed by default. Cursor is proprietary, and its built-in file tools aren't covered by the command sandbox.
OpenHands runs the agent in a Docker container by default and only sees what you mount. That's real isolation from your host, but the docs don't describe default network restrictions, and anything you mount read-write the agent can change. Avoid the process runtime, which OpenHands itself calls unsafe.
Strong sandbox, off by default
Claude Code has the most configurable sandbox of the group, but you have to turn it on with /sandbox. Then shell commands can only write to the working directory and temp, and network traffic goes through a proxy with an allowlist that starts empty. Two things to know. Reads are broad by default, including credential files like ~/.ssh and ~/.aws/credentials, so add them to filesystem.denyRead. And environment variables, including secrets, are inherited unless you list them under sandbox.credentials to deny or mask, or set CLAUDE_CODE_SUBPROCESS_ENV_SCRUB. Built-in file tools, MCP servers and hooks run outside the sandbox.
Kilo Code added an OS sandbox (Seatbelt on macOS, bubblewrap on Linux; no Windows) that is off by default. Once enabled, writes are limited to the workspace, .git stays read-only, and network is deny-by-default through an allowlist proxy. Kilo's docs are candid that it's not a confidentiality control: environment variables aren't scrubbed, and if the backend is missing it runs tools unsandboxed.
Gemini CLI supports more sandbox backends than anyone: Seatbelt profiles on macOS, Docker or Podman, gVisor on Linux and a native Windows sandbox. It's off by default; enable it with --sandbox. The default macOS profile limits writes but leaves reads and network open, so choose a stricter or proxied profile for untrusted work. Environment redaction is available but also off by default.
Approvals only
Cline, OpenCode, Goose and Aider don't sandbox commands. Instead they ask before acting, unless you enable auto-approve, which Cline's CLI does by default. OpenCode denies reads of .env files out of the box, a useful touch, but most of its permissions default to allow. Goose tried an experimental macOS sandbox in early 2026 and has since removed it. Approvals protect you only as long as you read each command carefully; for long or unattended runs, put these agents inside an external sandbox.
Autopilot
Autopilot, our terminal agent, takes a split approach. Its subagents, which do the parallel research on bigger tasks, each run read-only in their own Hotcell sandbox (container or microVM) with no real API key inside; they only get a short-lived, spend-capped token. The main agent runs on your machine and, in its default edit mode, asks before every mutating command. If you want the main agent sandboxed too, run Autopilot inside a Hotcell sandbox like any other agent.
Sandbox any agent from the outside
Built-in sandboxes vary, and almost none keep secrets out by default. The alternative is to run the agent itself inside an isolated environment whose keys stay on the host:
- Hotcell (Apache-2.0) runs agents in Docker containers, Firecracker microVMs or Apple Virtualization microVMs on your machine. Real API keys stay on the host; each sandbox gets a revocable token with spend caps, and outbound traffic can be default-deny.
hotcell create --opencodesets up OpenCode this way, and any other agent can be installed in a sandbox. - Docker Sandboxes run agents such as Claude Code, Codex, Gemini and OpenCode in microVMs, with credentials injected by a host proxy and deny-by-default networking. Free for local use; Docker doesn't describe it as open source.
We compare these and other options in local sandboxes for running AI agent subagents.
How to choose
| If you want… | Pick |
|---|---|
| Safe defaults with no setup | Codex CLI |
| The most control, and you'll configure it | Claude Code with /sandbox and credential masking |
| An IDE with sandboxed agent commands | Cursor, or Kilo Code with its sandbox on |
| Full container isolation for an autonomous agent | OpenHands in Docker |
| Keys that never enter the agent's environment | Any agent inside Hotcell or Docker Sandboxes |
FAQs
Is a sandbox enough to protect my API keys?
Usually not on its own. Most built-in sandboxes limit writes and network, but pass environment variables, including keys, to the commands they run. Turn on credential masking or scrubbing where the agent offers it, or keep keys out entirely with a proxy-based setup. Our guide on stopping coding agents from leaking API keys through subagents walks through it.
Are approval prompts as good as a sandbox?
No. Approvals depend on you spotting a bad command among many good ones, and most tools offer an auto-approve mode that removes them. A sandbox limits damage even when you approve something you shouldn't have.
Do these sandboxes work on Windows?
Codex CLI and Gemini CLI have native Windows sandboxes, and Docker Sandboxes runs on Windows too. Claude Code's sandbox doesn't run on native Windows (it works in WSL2), Kilo Code's sandbox doesn't support Windows, and Hotcell runs on macOS and Linux.
Which agent is safest for untrusted repositories?
One that runs in a VM-grade boundary with network off by default and no real keys inside: for example, any agent in a Hotcell microVM or a Docker Sandbox, or Codex CLI with network left off and secrets excluded from its environment.
