Running Coding Agents Safely with Docker Sandboxes

Core Concepts at a Glance

• YOLO mode (dangerously-skip-permissions) lets a coding agent run any command without asking. It is powerful, widely used, and risky.
• The fix is not to abandon YOLO mode. Approving hundreds of actions kills autonomy. The fix is to run the agent inside an isolated sandbox.
• Prompt guardrails are unreliable. Agents forget instructions during long sessions, so protection must be enforced by the environment, not requested of the model.
• Docker sandboxes provide free, one-command isolation across the file system, processes, network, Docker engine, and workspace.

Introduction

Every major coding agent (Claude Code, Cursor, Codex) ships a YOLO mode that skips permission prompts so the agent can work autonomously. That autonomy is exactly what makes these tools useful, but it also means the agent can touch anything on your machine. The chances of disaster are low because agents are smart, but it only has to go wrong once. This guide walks through the concrete risks, shows real failures, and demonstrates the primary solution: sandboxing the agent with Docker sandboxes.

1. The Risks of Running an Agent Directly on Your Machine

What

When an agent runs directly on your computer, it inherits your access. Three categories of risk follow.

Why it matters

• File system access: Assume any file or folder on the machine can be read, edited, or deleted, including things well outside your project.
• Environment and processes: The agent can kill processes and edit environment variables. Port conflicts often push it to kill running applications to get its current session working.
• Network exfiltration: A prompt injection attack can make the agent grab an API key and POST it to an attacker's URL. A network allow-list of permitted destinations blocks this.

How it is solved

Each risk maps to an isolation layer: file/process isolation, a separate set of processes and Docker engine, and network isolation restricting outbound requests.

2. Real Failure Examples

What

Cole demonstrates fabricated-but-realistic failures, then points to real ones from the Claude Code GitHub issues.

Why it matters

• Destructive cleanup: Agents will blow away node_modules and lock files and reinstall everything as a last-resort debugging move.
• One prompt flips it: The agent first protests a risky action, then a single "just go ahead" makes it wipe everything. Intelligence is not a guarantee.
• Secret reading: It will read private keys and env vars for debugging even after being told not to, reaching into ~/.ssh outside the codebase.
• Database damage: Unable to find a bug, it assumes the schema is wrong, rolls back and rewrites migrations, and can break the app.
• Real issues: rm -rf of a home directory, dropped production databases, and lost git stashes are all documented, closed as "not planned" because the model, not the tool, chose to do them.

How to think about it

These almost always happen late in a long conversation. Every LLM has a "dumb zone": the first ~100-200k tokens run at peak performance, but past 200-300k tokens context rot sets in and the model forgets earlier instructions, including its system prompt and your guardrails.

3. Why Prompt Guardrails Are Not Enough

What

Telling the agent what not to do is a soft control that degrades exactly when you need it most.

Why it matters

Because the agent forgets instructions in long troubleshooting sessions, you cannot rely on it to keep your rules in mind. Protection must be enforced by the sandbox rather than asked of the agent.

4. Getting Started with Docker Sandboxes

What

Docker sandboxes make isolation accessible: a single command to install, easy to configure, and they work with agents like Claude Code out of the box.

How

• Install with one command for Mac or Windows.
• Launch an agent with sbx run <agent> (for example sbx run claude). It looks like a normal terminal but runs inside an isolated VM.
• Your current directory is mounted in, so you work normally, but the rest of the machine (for example ~/.ssh) returns "not found".
• Outbound requests to sites not on the allow-list are blocked by the sandbox proxy (a 403 where the request never left the box). You manage the allow-list of permitted sites.
• You can hand the Docker sandbox documentation to the agent and have it configure and test the sandbox for you.
• Ask the agent to prove isolation: try to read host files, reach host services, or touch the host Docker socket. All should fail.
• Default mode mounts your real files; add --clone to work on a full copy so the agent never touches your actual codebase or git history.

5. The Isolation Layers

What

Docker sandboxes stack several layers of isolation.

• Hypervisor isolation: process and file system isolation so the agent cannot close host processes or delete host files. sbx rm deletes the VM and everything in it for full cleanup.
• Sudo inside the VM: the agent runs with full privileges inside the sandbox because nothing it does there can escape.
• Network isolation: requests are limited to allow-listed sites via managed policies.
• Docker engine isolation: a separate Docker engine keeps sandbox containers out of your bloated host Docker desktop.
• Workspace isolation: direct mount for editing local files, or clone mode for a fully separate copy.

Closing Summary

YOLO mode is essential for autonomous coding agents, but running one directly on your machine exposes your files, processes, secrets, network, and databases. Because agents lose their guardrails during long sessions through context rot, you cannot trust prompt-level protections. The durable answer is environment-enforced isolation. Docker sandboxes deliver that in a single free command, giving the agent full freedom inside a disposable VM while keeping your real machine completely protected.