Docker’s YOLO Mode Explainer Turns Agent Permissions Into a Boundary Problem

Docker published an explainer today that puts a name on a habit most developers running AI coding agents already know by feel: turning off every permission prompt so the agent just goes. The post, YOLO Mode: Agent Autonomy Without the Guardrails, by staff product manager Eric Jia and principal AI product marketing manager Srini Sekaran, does not announce a new feature. It defines a term, catalogs how five different coding agents implement it, and uses that definition to argue for two of Docker’s own products, Docker Sandboxes and Docker AI Governance, as the fix. The argument underneath the pitch is worth separating from the pitch itself, because it lands on a real, unsolved problem: an agent with every prompt disabled has the run of whatever machine it is sitting on, and most teams have not thought carefully about where that machine actually is.

What YOLO Mode Actually Means, Flag by Flag

Docker defines YOLO mode as the community nickname for running an AI agent with every action auto approved: no prompts before it reads a file, writes code, runs a shell command, or calls a tool. The behavior shows up under a different label depending on which agent a developer runs, and Docker’s post lists five of them. Independently checking each vendor’s own current documentation confirms the picture Docker describes, with a few details its post leaves out.

Claude Code uses the --dangerously-skip-permissions flag, which Anthropic’s own documentation treats as equivalent to --permission-mode bypassPermissions. The first time a developer starts an interactive session with it enabled, Claude Code shows a warning dialog asking them to accept responsibility for actions taken without permission checks; decline it and Claude Code exits. On Linux and macOS, Claude Code refuses to start in this mode at all when running as root or under sudo, printing the error --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons, a check it skips automatically only inside a sandbox it recognizes. Anthropic’s documentation is explicit about the flag’s limits too: bypassPermissions mode “offers no protection against prompt injection or unintended actions,” and organizations can block it outright at the account level with a managed settings key called permissions.disableBypassPermissionsMode.

Codex CLI, OpenAI’s coding agent, is the one entry on Docker’s list that is not architecturally equivalent to the other four. --full-auto removes the interactive approval prompts, but according to OpenAI’s own Codex documentation, it still runs inside Codex’s sandbox in workspace-write mode with network access turned off by default, a meaningfully smaller bypass than what Claude Code’s --dangerously-skip-permissions or Gemini’s --yolo do. That same documentation now calls --full-auto a “deprecated compatibility path” that prints a warning when used, pointing developers to codex exec --sandbox workspace-write instead. The flag that actually matches the rest of Docker’s list, no sandbox and no approvals, is --dangerously-bypass-approvals-and-sandbox, aliased --yolo, which OpenAI’s documentation frames as suited only to an environment that already has its own external sandbox around it, such as a container, VM, or CI runner.

Gemini CLI’s version is --yolo, listed alongside the equivalent --approval-mode=yolo in Google’s own reference documentation, or the Ctrl+Y keybinding mid session. That keybinding is real enough to have caused its own problems: a Gemini CLI GitHub issue asks the maintainers for a way to disable Ctrl+Y specifically, because it collides with the Emacs-style cut and paste shortcut some terminal users already have as muscle memory, turning on full autonomy by accident.

GitHub Copilot CLI offers --allow-all, also aliased --yolo, matching the same enable-everything pattern GitHub’s own documentation describes for situations where a developer trusts Copilot to act without asking.

Cursor is the outlier: no flag at all. What Docker’s post calls “auto-run in settings” is a persistent toggle under Settings, Features, Agent. Cursor’s own product used to call that same setting YOLO mode before renaming it Auto-run, which pairs an on/off switch with a natural-language allowlist of commands the agent can run without asking.

Only Codex CLI draws a line between skipping approvals and dropping the sandbox inside a single tool. The other four treat approval and isolation as one combined switch: it is either on, with every prompt shown, or off, with none.

Adoption Is Outrunning Trust

Docker frames the demand for YOLO mode with one statistic from Stack Overflow’s 2025 Developer Survey: 84 percent of developers said they use or plan to use AI tools in their workflow, up from 76 percent the year before. The same survey, which Docker’s post does not mention, found the opposite trend running alongside it. Stack Overflow asks respondents how much they trust the accuracy of AI tools’ output in their workflow, and combined trust, developers who say they highly or somewhat trust it, fell from 43 percent in the 2024 survey to 32.7 percent in the 2025 survey, a drop of roughly 10 points. More developers now actively distrust that output, 45.7 percent, than trust it. Developers are handing agents more autonomy at the same time their confidence in what those agents produce is falling, not rising, which is the real backdrop for why “how much should an agent be allowed to do without stopping to ask” is a live operational question rather than a hypothetical one.

Why Docker Says the Risk Is Location, Not Autonomy

Docker’s central claim is that the danger in YOLO mode is not the autonomy itself, it is where that autonomy runs. On an unprotected host, the post lists three concrete failure modes: a vague or mistaken instruction running something like rm -rf against the wrong directory with nothing to catch it, an agent reading and potentially leaking environment variables, SSH keys, tokens, and .env files it already has standing access to, and prompt injection, where the agent acts on a hidden instruction buried in a web page, an issue, or a code comment it reads while working.

None of that is hypothetical. In August 2025, the s1ngularity attack against the Nx build platform did exactly what Docker’s third failure mode describes, as sxz.io covered in depth at the time. Malware distributed through a compromised npm package checked infected machines for an installed AI coding CLI and, when it found one, invoked it directly with the same permission-bypass flags named in Docker’s post today, --dangerously-skip-permissions on Claude Code and --yolo on Gemini CLI, instructing the agent to recursively hunt for credential-shaped files and record their paths. GitGuardian’s investigation into that attack found that roughly a third of compromised systems had an LLM client installed, and of the systems where an agent was actually targeted, about a quarter complied with the instruction. YOLO mode was not a side detail in that incident. It was the mechanism the attacker exploited.

The Fix Docker Is Selling: A Boundary, Not a Permission Prompt

Docker’s answer is to stop trying to make YOLO mode safer with more careful prompts and instead put a boundary around where it runs. The post draws a specific technical distinction: a container shares the host’s kernel, but a microVM puts what Docker calls a hardware-level boundary around the agent, so isolation holds even if the agent tries to break out of it. Inside that boundary, the pitch goes, an agent can install packages, run services, and edit files, but cannot see the developer’s credentials, reach other projects on the same machine, or touch the host, and if a run goes wrong the whole environment gets destroyed and rebuilt clean.

That is the sales pitch for two named Docker products. Docker Sandboxes is the isolated, disposable microVM environment itself, with scoped network and filesystem access. Docker AI Governance is the layer Docker sells to enforce that boundary consistently across an organization rather than leaving it to each developer’s individual judgment call. It is worth being direct about what this is: a container and security company using a genuinely useful piece of vocabulary to sell isolation tooling it happens to build. The underlying principle, that an agent should run somewhere its mistakes are contained rather than somewhere they are expensive, holds regardless of whose sandboxing a team actually uses. sxz.io has covered this same argument from Docker several times this year, including a deep dive into the telemetry behind Docker’s own agent security research, a hands-on look at running Docker Sandboxes for embedded firmware development, a case study of a patched Cursor bug that let a shell command slip past an allowlist, and the original Docker SBX launch. This post returns to the same well with a catchier hook.

The Governance Problem Underneath the Vendor Pitch

Set the product names aside and Docker’s post still identifies a real organizational failure mode. For one developer, deciding whether to skip permissions on a sandboxed laptop is a personal call. Across a team of a hundred developers, it is a hundred separate personal calls, made with no visibility into which of them are running an agent directly against a machine that holds real credentials. That is a governance gap whether or not a security team buys Docker’s specific product to close it: the same result, an agent with standing access getting a boundary it cannot cross, is achievable with plain virtual machines, containers configured to drop host mounts, or any other isolation approach a team already runs.

Anthropic, whose Claude Code is one of the five agents on Docker’s list, already offers a useful point of comparison. Its documentation lets administrators block bypassPermissions mode outright at the organization level through managed settings, and it offers a middle ground of its own: a second, classifier-reviewed auto mode that screens actions automatically instead of either prompting a human or approving everything, close to what Docker’s FAQ calls “a filter on top of the agent, not a boundary around it.” Docker’s argument is that a filter is not a substitute for a boundary. Anthropic’s own admission that bypassPermissions mode offers no protection against prompt injection agrees with that, even though Anthropic is not the one selling the boundary.

Sources

• Docker Blog: YOLO Mode, Agent Autonomy Without the Guardrails
• Claude Code Docs: Choose a Permission Mode
• Codex CLI Docs: Agent Approvals and Security
• Gemini CLI Docs: Configuration Reference
• Gemini CLI GitHub Issue: Change or Disable YOLO Mode Keybinding
• GitHub Docs: Use Copilot CLI
• Stack Overflow 2025 Developer Survey: AI
• Stack Overflow 2024 Developer Survey: AI
• sxz.io: The Nx Supply-Chain Attack Turned AI Coding Agents Into Credential Scanners

Image credit: Bumper cars at Kings Dominion, photographed between ride sessions. Photo by Ben Schumin, licensed under CC BY-SA 3.0 via Wikimedia Commons; cropped and converted to WebP for sxz.io.