Why your coding agent's YOLO mode is one bad prompt away from disaster

Somewhere on Reddit right now, a developer is describing the moment their AI coding agent deleted a production database, wiped uncommitted work, or quietly shipped an API key to a server in another country. It didn't happen because the agent was malicious. It happened because someone turned on the one setting that every coding agent ships with, the one that removes every single guardrail between the model and your machine.

That setting has a name, and the name is doing you a favor by sounding scary: dangerously skip permissions.

What is YOLO mode and why does everyone turn it on?

Every major coding agent — Claude Code, Codex, Cursor, Gemini CLI, and the rest — has a flag or setting that stops it from asking permission before every action. In Claude Code, that flag is --dangerously-skip-permissions, and the community nickname stuck for a reason. Dangerous skip permissions is a mechanic in Claude Code that uses the --dangerously-skip-permissions flag to enter YOLO mode, bypassing all permission checks and eliminating safety guardrails entirely.

The appeal is obvious the second you use it. When you are iterating on a feature, fixing bugs, or refactoring code, Claude asks for permission before every action: editing a file, running a test, installing a package, using an MCP tool. On a typical task, that can mean dozens of prompts. Most developers just spam "yes" anyway, which defeats the purpose of having safeguards. Once you flip on skip-permissions, all of that friction disappears. YOLO mode removes all those prompts at once. Claude reads, writes, runs commands, and calls tools without asking.

Here's the part that should give you pause: the mental model isn't "the agent has some access." The mental model is that Claude operates with the same access as if you were typing the commands yourself. That means your filesystem, your database credentials, your SSH keys, your cloud CLI sessions — all of it is fair game, with nothing standing between a bad instruction and your real machine.

Why doesn't the built-in sandbox protect you?

Most agents now ship some form of built-in sandboxing to reduce exactly this risk, and it genuinely helps. Anthropic's own engineering team explains the motivation plainly: giving Claude this much access to your codebase and files can introduce risks, especially in the case of prompt injection. Their sandboxing approach creates pre-defined boundaries within which Claude can work more freely, instead of asking for permission for each action. With sandboxing enabled, you get drastically fewer permission prompts and increased safety. It works, too — in Anthropic's internal usage, they've found that sandboxing safely reduces permission prompts by 84%.

But "reduces risk" is not the same as "eliminates risk," and Anthropic is upfront about that distinction. Their own documentation states it directly: sandboxing reduces risk but is not a complete isolation boundary. Review the limitations below before relying on it as a hard security control. That's not marketing hedge language — it's a real technical limitation. For example, sandboxed Bash commands inherit the parent process environment by default, including any credentials set there, and when Claude opens apps and controls your screen, it runs on your actual desktop rather than in an isolated environment.

This isn't hypothetical, either. Security researchers found a real bypass in Claude Code's sandboxed egress controls, where the dangerous chain requires a vulnerable runtime, a useful egress bypass path, readable credentials or sensitive data, and some way for attacker-influenced code or instructions to run inside the sandbox. Developer machines often hold AWS credentials, GitHub CLI tokens, SSH keys, npm tokens, kubeconfig files, and model API keys, so the blast radius can be high when those conditions are met. Anthropic's own API documentation is just as blunt about where responsibility shifts to you: Anthropic's security boundary stops at the sandbox. How you isolate individual tool executions from each other inside that boundary is entirely your responsibility.

Why can't you just write better rules?

The instinct after reading a horror story is usually "I'll just write stricter rules — block rm -rf, block pushing to main, block reading .env files." Rules help, but they fail in a specific and predictable way: long conversations degrade an agent's judgment.

Coding agents are genuinely sharp early in a session. But the longer a conversation runs, the more context accumulates, the more the model's attention gets diluted, and the more likely it is to do something a first-year developer would know not to do — delete the wrong branch, overwrite a config it wasn't supposed to touch, or follow an instruction buried in a file it was reading instead of one you actually gave it. Rules written in plain English are suggestions to a language model, not hard constraints enforced by an operating system. An agent that's confused, exhausted its context, or been fed a malicious instruction through a prompt injection attack can simply decide the rule doesn't apply right now.

That last part — prompt injection — is the scenario that should worry you most, because it doesn't require a hacker breaking into anything. It just requires your agent to read something it shouldn't fully trust: a webpage, a GitHub issue, a dependency's README, a Slack message pulled in through an MCP tool. If that text contains hidden instructions, an unrestricted agent can follow them, grab an environment variable holding an API key, and send it straight to a URL an attacker controls. The only real defense against that isn't a smarter prompt — it's a network allowlist that physically prevents the agent from reaching any URL you haven't approved, so even a successfully injected instruction has nowhere to send stolen data.

How do you actually run a coding agent safely?

The fix that works isn't better prompting — it's real isolation, at the operating-system level, so that even a worst-case outcome (the agent runs something catastrophic) only destroys a disposable environment instead of your actual machine. This is where Docker Sandboxes comes in, and it's currently the most practical way to get YOLO-mode speed without YOLO-mode risk.

Docker Sandboxes runs each agent session inside its own isolated microVM rather than a shared container, which matters because it means the agent doesn't share a kernel with your host at all. Instead of standard containers that share the host machine's kernel, sbx spins up an entirely independent lightweight MicroVM for each agent session. This guarantees that even if an AI agent runs a destructive command like rm -rf /, your host operating system and sensitive local data remain completely safe.

It also solves the credential-leaking problem directly. Your actual LLM API keys are stored securely in your host machine's OS keychain via the built-in Docker Sandboxes Secrets Manager, and a host-side proxy intercepts traffic and injects authorization headers on the fly, meaning the AI agent can never read, log, or exfiltrate your raw API keys. And on the network side, it defaults to locked down rather than wide open: network access is deny-by-default, and when you first authenticate, you choose a configuration — Open, Balanced, or Locked Down — with outbound traffic restricted via a host-side firewall, preventing unauthorized egress from inside the sandbox.

How do you set it up?

Getting started takes only a few commands. Docker's own sbx CLI reference and the sbx run documentation walk through the full command set, but the core workflow looks like this:

1. Install the sbx CLI. On Mac, that's a single Homebrew command; Docker's docs cover Windows and Linux equivalents too.
2. Authenticate once. The CLI opens a browser for Docker OAuth, and it's a one-time setup step.
3. Launch a sandbox with your agent of choice. Available agents include claude, codex, copilot, cursor, docker-agent, droid, gemini, kiro, and opencode. Running sbx run claude from your project directory mounts your current folder into an isolated VM session.
4. Let the agent run in skip-permissions mode — safely. Because the whole session lives inside the microVM, you can set Claude to work, and it runs in --dangerously-skip-permissions mode, without needing to prompt you every time it needs to use a tool.
5. Review and merge when it's done. Depending on whether you use direct or branch mode, the agent either edits files in your working directory and commits directly to git, or sbx creates a git worktree in a hidden sub-folder and starts the agent there — giving you a clean diff to review before anything touches your real branch.
6. Set a network policy. You can inspect and adjust what a sandbox is allowed to reach with sbx policy ls, keeping the agent's egress limited to only the domains it actually needs.

If you want to test the waters before pointing a real agent at your codebase, Docker also supports a bare shell mode. sbx run shell drops you into a Bash login shell inside a sandbox with no pre-installed agent binary, which is useful for installing and configuring agents manually, testing custom implementations, or inspecting a running environment.

What else should you check before every YOLO session?

Even with sandboxing, a few habits make a real difference:

• Commit before you run anything unattended. A clean git state means git reset --hard can undo whatever the agent did, sandbox or not.
• Use an allowlist, not a blocklist, for network access. Blocking known-bad domains means you're always one step behind. Allowing only known-good domains means an injected instruction has nowhere to send stolen data even if it gets that far.
• Keep sessions short and scoped. A narrow instruction like "refactor the auth middleware to use JWT" gives the model far less room to wander than an open-ended "improve the codebase."
• Separate credentials by trust boundary. If you're running agents against multiple projects or untrusted code, don't reuse the same API keys and tokens across all of them.

What's the real takeaway here?

YOLO mode isn't the villain — unrestricted YOLO mode on your actual machine is. The speed that makes skip-permissions mode so addictive is exactly what makes an unsandboxed setup so risky: the agent moves fast enough that by the time something looks wrong, it's already done. Put a real isolation boundary underneath it — a microVM, a locked-down network policy, a disposable filesystem — and that same speed becomes something you can actually trust instead of something you're gambling with every time you hit enter.

The next time you're tempted to run --dangerously-skip-permissions directly on your laptop because setting up a sandbox feels like one extra step, ask yourself what's actually sitting in that directory. Your SSH keys are probably in there. So is everything you'd lose in the ten seconds it takes for one bad instruction to go the wrong way.