What is sandboxing? (the walls around your agent)

What it actually is

Sandboxing means running code inside a sealed environment where it can’t touch your file system, your network, or your accounts unless you explicitly allow it. The name comes from the playground kind. A kid in a sandbox can dig and knock things over, and the mess stays inside the wooden frame. Code in a sandbox gets the same deal: it can compute whatever it wants, and the walls decide what it can reach.

You already trust a sandbox every day. Your browser runs every website’s JavaScript inside one. A random page from a search result is executing a stranger’s code on your machine right now, and it can’t read your tax documents or install anything, because the browser’s sandbox says no. That is most of the reason casual web browsing is survivable.

Two heavier cousins come up in the same conversations, one line each. A container packages an app and runs it in its own isolated slice of your operating system. A virtual machine (VM) goes further and simulates an entire separate computer, operating system included, inside yours. Same idea, thicker walls, more overhead.

Why your AI just did this

Agentic coding means your AI runs shell commands for you: installing packages, running tests. Each command runs with whatever access it’s given, and on a normal machine that means everything you can touch. So agent tools draw walls. Claude Code ships a Bash sandbox (type /sandbox to see it): by default, commands can write only inside your project folder and a temp directory, and the first time a command wants to reach a new network domain, you get asked. Cursor likewise runs agent terminal commands in a sandbox that blocks unauthorized file access and network activity.

The wall holds because your operating system enforces it. On a Mac that’s a built-in framework called Seatbelt; on Linux it’s a tool called bubblewrap. The limits apply to the running process itself, so they hold even when a command does more than its name suggests, or when a prompt injection talks your agent into running something hostile.

Those permission prompts you keep answering are doors in that wall. “Allow this command?” or “Allow access to registry.npmjs.org?” is your agent standing at a door, asking you to open it. A yes opens that one door. The rest of the wall stays up.

When you’ll run into it

The everyday sighting is the prompt itself: Claude Code pausing to ask before a command touches a domain or path you haven’t approved. You’ll also meet the wall when a command that works fine in your own terminal fails inside the agent, often with a permission error, because the sandbox blocked a write outside the project. When that happens, Claude Code may ask to retry the command outside the sandbox, and that request goes through the normal permission flow, so you still get a say.

Some tools don’t fit in the box at all. docker is incompatible with Claude Code’s sandbox and has to run outside it, which is a documented config choice, not a bug in your project.

The riskiest moment involves no agent at all: pasting npx some-tool or curl ... | sh from a stranger’s README straight into your regular terminal. Outside a sandbox, that code runs as you. It can read your .env files and the SSH keys in ~/.ssh, then send them anywhere. Inside a sandbox, the same code gets a sealed room and a network door that opens only with your approval.

What to check

• Run /sandbox in a Claude Code session to see whether the sandbox is on and how commands get approved
• Read each permission prompt before answering; it names the exact command, path, or domain, and that is the door you’re opening
• Ask your agent why a command needs to run outside the sandbox before you approve the retry; a blocked command deserves a second look
• Block your secret files by name; Claude Code’s default sandbox still allows reading ~/.aws/credentials and ~/.ssh, and its sandbox.credentials setting closes that gap
• Run strangers’ code (a cloned repo, an npx one-liner from a forum) inside a sandbox, or read it before you run it
• Pair the wall with least privilege: the sandbox limits where code can go, and tight keys limit what it can do once it gets there

Say it like a dev

Instead of: “my AI asks me to approve every single command so I just spam yes” Say: “Can we enable the Bash sandbox in auto-allow mode, so contained commands run on their own and I only get asked when something crosses the wall?”

Instead of: “the command randomly failed even though it works in my terminal” Say: “This looks like a sandbox restriction, probably a blocked write or an unapproved network domain. What access does this command need?”

Instead of: “turn the security stuff off so it stops asking” Say: “Keep the sandbox on. If a command needs more access, ask me for the specific path or domain instead of running it unsandboxed.”