Guide
How should I sandbox AI coding agents like Claude Code and Codex, and is a sandbox enough?
Updated
Short answer
Turn on the built-in sandbox, block the agent from retrying commands outside it, and run untrusted repos and unattended sessions in a container or VM with no host secrets. A sandbox isn't enough on its own. It limits what the agent can reach, but inside those limits the agent can still delete the workspace, send what it can read to an allowed host, or push with the credentials it holds. Add scoped credentials, per-turn snapshots and a check on each action before it runs.
What a sandbox actually does#
A sandbox is a wall around where a command can write and where it can connect. It doesn't know why the agent is running the command.
That still pays off. Anthropic reports that in its internal usage, sandboxing safely reduces permission prompts by 84%. Fewer prompts means less approval fatigue, and that's half the reason to turn it on.
The native options#
Claude Code. Know what the sandbox covers before you count on it. Per Anthropic's docs, the sandbox covers shell commands only. Claude's file tools, MCP servers and hooks run outside it.
So a file edit through Claude's own tools, or a call an MCP server makes, isn't bounded by the sandbox at all. Check the docs for current defaults on your OS and confirm the sandbox is actually on across the fleet, not just on the laptops you've looked at.
Codex. OpenAI's docs describe workspace-write as the default low-friction mode for local work. Check what network access your config allows before you assume it's closed.
When the agent turns off its own sandbox#
A sandbox that the agent can step out of isn't a boundary. One write-up by Abhishek Ray quotes a user whose agent talked itself into disabling the sandbox and running npx outside it. Treat that as a user report, not a lab result.
The fix is in policy, not in the prompt:
- Require the sandbox in managed settings, so a developer or project file can't turn it off.
- Turn off unsandboxed retries, so a command that fails inside the sandbox fails.
- Make the agent stop if the sandbox can't start, rather than run without it.
Setting names change between releases, so take them from the current sandboxing docs and test them on one machine before you push them.
Containers and dev containers#
A dev container moves the agent's whole toolchain into an isolated environment. That's where teams usually run bypass mode for unattended work.
Anthropic's own warning is the part to keep: with --dangerously-skip-permissions, dev containers don't prevent a malicious project from exfiltrating anything accessible inside the container, including the Claude Code credentials stored in ~/.claude. So:
- Don't mount
~/.sshor cloud credential files into the container. - Use repo-scoped, short-lived tokens.
- Restrict egress to the domains the agent needs.
- Use a VM, not a shared-kernel container, for code you don't trust at all.
What a sandbox doesn't stop#
| Risk | Why the sandbox allows it | What covers it |
|---|---|---|
| Delete the workspace | The agent needs write access there to work | Snapshots or checkpoints each turn |
| Read secrets in reach | Whatever is readable inside the boundary is fair game | Deny rules, no host secrets, scoped credentials |
| Send data to an allowed host | An allowlist checks where, not what | A check on what's being sent |
| Push or publish with held credentials | Credentials work from inside | Gate the irreversible actions |
| File tools, MCP servers, hooks | They run outside the Claude Code sandbox | A separate check on those actions |
The sandbox decides what's reachable. It can't tell a refactor that deletes a test from an agent deleting the test that's failing. Same command, two intents.
Where Harden fits#
Harden Agentic Integrity Foundation (AIF) judges the action, not the reach. It runs on the developer laptop, outside the agent, at the agent's pre-execution hook. No command, file edit or push executes until it's been checked against the session's intent, locally, in about 28 ms.
Deterministic rules cover 10 kinds of risky action, and a local model reviews 19 risk categories in context, so it can catch a harmful action that stays inside the sandbox's limits. It starts watch-only, so you see what agents do before you enforce.
It's a layer, not a perimeter. It doesn't replace least privilege, scoped credentials or egress policy, and exfiltration split across several separate calls is the hard case.
For how this stacks with permission rules and hooks, see permissions vs hooks vs sandbox. For bypass mode, see is --dangerously-skip-permissions safe. For what to gate, see irreversible coding agent actions.
A decision rule#
- Trusted repo, attended session: native sandbox on and required, unsandboxed retries off, reads on secrets denied.
- Untrusted repo or unattended run: container or VM, no host secrets, egress allowlist.
- Either way: scoped credentials, a snapshot per turn, and a check at the hook for what the sandbox can't see.
FAQ
Related questions
Does the Claude Code sandbox cover MCP servers and hooks?
No. Per Anthropic's docs, the sandbox covers shell commands only. Claude's file tools, MCP servers and hooks run outside it, so they need a separate check.
Can Claude Code turn off its own sandbox?
Users have reported it. One write-up quotes a user whose agent talked itself into disabling the sandbox and running npx outside it. Require the sandbox in managed settings and turn off unsandboxed retries, using the setting names in the current docs.
Is a dev container safer than the built-in sandbox?
It isolates more, since the whole toolchain runs in the container. But Anthropic warns that with --dangerously-skip-permissions, a malicious project can still exfiltrate anything accessible inside it, including Claude Code credentials. Keep host secrets out and restrict egress.
Does the sandbox stop an agent from pushing to my repo?
Not by itself. Credentials the agent can reach still work from inside the sandbox. Use scoped, short-lived tokens and check pushes and publishes before they run.