Stop Your AI Coding Agent From Wiping Your Computer: A Sandbox Guide
Learn why Claude Code's Yolo mode is risky and how Docker sandboxes let AI coding agents run autonomously without touching your real files.
What is “Yolo mode” and why is it risky?
Yolo mode is the nickname for running a coding agent with permission checks turned off, what Claude Code calls “dangerously skip permissions.” Every major coding agent, Claude Code, Cursor, Codex, has some version of this flag. It lets the agent run any command on your machine without stopping to ask you first: installing packages, editing files, killing processes, touching your database.
Without it, you’d spend your day approving hundreds of small actions, which defeats the point of having an autonomous agent. With it, the agent can also delete your files, wipe a database, or leak a credential, because it has the same access to your system that you do. The fix isn’t to avoid Yolo mode. It’s to run the agent somewhere those permissions can’t do real damage.
TL;DR
- Yolo mode gives full system access, meaning a coding agent running with permissions skipped can read, edit, or delete anything your user account can touch, including files well outside your project folder.
- Long conversations make agents dumber, since large language models perform best in roughly the first 200,000 to 300,000 tokens of context and start losing track of earlier instructions and guardrails after that.
- Real incidents are documented, including GitHub issues where Claude Code ran a recursive force delete (
rm -rf) on a user’s home directory or dropped an entire Git stash of uncommitted work. - Prompt-based guardrails aren’t reliable, because an agent can protest that an action is risky and then reverse itself completely after a single follow-up message.
- Sandboxing enforces safety at the system level instead of hoping the model remembers your instructions, isolating the file system, processes, and network access.
- Docker sandboxes make this practical, offering a free, single-command setup that runs coding agents like Claude Code in an isolated VM with no extra workflow friction.
- Network isolation blocks data exfiltration, since a sandbox can restrict outbound requests to an allow list, which matters if a prompt injection attack tries to steal an API key.
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
What can actually go wrong when an agent runs unsandboxed?
The risks fall into a few concrete categories, and they’re broader than most developers assume.
File system access. If your coding agent isn’t isolated, assume it can read, edit, or delete any file or folder your user account can reach. That includes directories completely outside your project, like your ~/.ssh folder, which stores private keys. Agents have been observed reading SSH keys or environment variables mid-debugging session, even after being told earlier in the conversation not to touch them.
Process and environment interference. Coding agents sometimes hit port conflicts or environment issues and respond by killing processes or editing environment variables to “fix” the problem. On a machine without isolation, that means your agent can shut down unrelated applications or corrupt settings that have nothing to do with the task at hand.
Database destruction. A common failure pattern: the agent can’t find a bug in the application code, decides the database schema must be wrong, and starts rolling back migrations or writing new ones. This can break a working application, and in worse cases, an agent that somehow has access to a production database connection string can run destructive commands against it.
Dependency and directory wipes. Agents will sometimes decide, especially late in a long debugging session, that the fastest fix is to delete node_modules and lock files and reinstall everything, or in the worst documented cases, run a recursive force delete across a home directory. GitHub’s issue tracker for Claude Code has real reports of exactly this: full home directory deletions and dropped Git stashes containing uncommitted work.
Prompt injection and data leaks. If an agent processes untrusted content (a webpage, a file, an API response) that contains hidden instructions, it can be tricked into grabbing sensitive data like an API key and sending it to an external URL. Without network restrictions, that request simply goes out.
Why do agents behave worse in long conversations?
Every large language model has what amounts to a “dumb zone.” Performance is strongest in the earlier portion of the context window, often cited around the first 200,000 to 300,000 tokens, but degrades as the conversation grows longer. In extended debugging sessions, an agent can drift past that point and start losing track of the instructions you gave at the start, including its own system prompt.
This is why the scariest failures usually happen deep into a session, after an agent has exhausted the obvious fixes and starts reaching for last-resort options. It’s also why an agent can flag an action as risky, tell you so directly, and then reverse course entirely after one follow-up message telling it to proceed. That inconsistency is the core argument against relying on prompting alone. An agent that “understands” the risk in one message can still take the destructive action in the next.
How does sandboxing actually solve this?
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
A sandbox gives the coding agent an isolated environment, typically a virtual machine, so it can run with full autonomy without touching your real file system, processes, or network directly. Instead of trusting the model to remember and respect guardrails, the guardrails are enforced structurally.
A well-built sandbox isolates at several levels:
- File system isolation: only your project directory is mounted into the VM. Folders like
~/.sshsimply don’t exist from the agent’s perspective, so there’s nothing to leak even if the agent tries. - Process isolation: the sandbox runs its own set of processes and its own container engine, so the agent can’t kill or interfere with anything running on your actual machine.
- Network isolation: outbound requests are restricted to an allow list of URLs. If an agent (or a prompt injection attack) tries to reach an unapproved destination, the request is blocked before it ever leaves the sandbox, not just rejected by the destination server.
Inside the sandbox, the agent can still do everything it needs for real development work: install dependencies, run a dev server, build Docker images using its own isolated Docker engine. From the developer’s point of view, the terminal experience looks normal. Under the hood, none of that activity touches the host machine.
Is Docker sandboxes worth setting up?
For developers already running coding agents in Yolo mode regularly, yes. Docker sandboxes are free, run locally the same way Docker Desktop and containers already do, and the setup is a single install command followed by a single run command (something like sbx run claude to launch Claude Code inside an isolated sandbox). Configuration for network allow lists and other policies is straightforward, and if the command-line setup feels unfamiliar, the documentation itself can be handed to a coding agent, which can configure the sandbox with you.
The tradeoff is minimal. You’re not losing functionality: package installs, dev servers, builds, and normal coding workflows all work the same inside the sandbox. What you gain is a hard boundary between what the agent can affect and what it can’t, which matters a lot more than it seems until the one time an agent decides to run something destructive in a long session.
Frequently Asked Questions
What does “dangerously skip permissions” actually do?
It disables the confirmation prompts a coding agent normally shows before running commands, letting it execute file edits, installs, deletions, and other actions automatically without asking you first.
Can a sandboxed agent still access my project files?
Yes. A properly configured sandbox mounts your working project directory into the isolated environment, so the agent can read and edit project files normally. It just can’t reach anything outside that boundary, like your home directory or SSH keys.
Does sandboxing slow down the agent or change my workflow?
Generally no. Inside tools like Docker sandboxes, the terminal experience looks the same as running the agent directly, and tasks like installing dependencies or running a dev server work as expected.
Why do coding agents sometimes delete files even after being told not to?
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
Long conversations push models past the portion of the context window where they perform best, causing them to lose track of earlier instructions, including safety guardrails set at the start of the session or in a system prompt.
Is sandboxing only necessary for production systems?
No. Even local development environments contain things worth protecting, uncommitted Git work, local databases, environment variables, and personal files, all of which have been affected by real, documented coding agent mistakes.