# Claude Dangerously Skip Permissions: YOLO Mode Without Risking Your Machine

> Stop babysitting permission prompts. What Claude Code --dangerously-skip-permissions and Codex --yolo really turn off, and the boundaries that make it safe.

By mid-afternoon the prompts all look the same. `npm test` — allow. `git diff` — allow. `mkdir -p src/lib` — allow. I stopped reading them hours ago; I'm a human `yes` command with a coffee habit. That's the moment people go looking for `claude --dangerously-skip-permissions`, and it's the right instinct aimed at the wrong fix.

Claude Code's `--dangerously-skip-permissions` and Codex's `--yolo` remove the prompts, not the risk. Run them only behind a boundary the agent can't argue with: a container or VM, an OS-level write sandbox, deny rules for the few commands you never want, and no credentials worth stealing. Do that, and YOLO mode is simply fast.

I have an unusual vantage point on this. [Octomind](https://octomind.run), the agent runtime we build, has no permission prompts at all. That was a deliberate call: an approval you give on reflex stops being a decision. So we put the effort into boundaries instead. Below is what the flags really switch off, a probe I ran through four different boundaries, and the setup I'd actually use.

## What the Claude Code dangerously skip permissions flag actually turns off

It turns off everything that would have asked you. Here is how Claude Code 2.1.287 describes the flag in `claude --help`:

```text
--dangerously-skip-permissions        Bypass all permission checks.
                                      Recommended only for sandboxes with no
                                      internet access.
```

It is the same thing as Claude Code's bypass permissions mode, `--permission-mode bypassPermissions`. Its sibling, `--allow-dangerously-skip-permissions`, only adds the mode to the Shift+Tab cycle without switching it on — useful if you want Claude Code YOLO mode one keystroke away rather than as your starting state. The command has three common forms:

```bash
claude --dangerously-skip-permissions
claude --permission-mode bypassPermissions
claude -p "fix the failing tests" --dangerously-skip-permissions
```

A few things survive. According to Anthropic's [permission modes documentation](https://code.claude.com/docs/en/permission-modes), deny rules still block in every mode, including this one (allow rules simply stop mattering). `rm` and `rmdir` aimed at critical paths — the filesystem root, your home directory, your working directory — are never auto-approved: depending on the target, Claude Code asks with a two-minute countdown in the terminal or denies the command outright. And on Linux and macOS, Claude Code refuses to start in this mode as root or under `sudo`.

What doesn't survive is any judgment about intent. The docs are blunt: "`bypassPermissions` offers no protection against prompt injection or unintended actions," and the mode is meant for "isolated environments like containers, VMs, or dev containers without internet access, where Claude Code cannot damage your host system."

Since 2.1.283, Claude Code starts interactive sessions in auto mode, where a classifier model reviews actions instead of you. That's a real middle ground, but Anthropic's own [sandbox guide](https://code.claude.com/docs/en/sandbox-environments) calls the classifier "a per-action control, not an isolation boundary." Fewer prompts, same exposure if it guesses wrong.

## Codex has no dangerously-skip-permissions flag — it has --yolo

The Codex equivalent of `codex dangerously-skip-permissions` is `--dangerously-bypass-approvals-and-sandbox`, and `--yolo` is its alias. From `codex exec --help` on codex-cli 0.159.3:

```text
--dangerously-bypass-approvals-and-sandbox
    Skip all confirmation prompts and execute commands without sandboxing. EXTREMELY
    DANGEROUS. Intended solely for running in environments that are externally sandboxed
```

`--yolo` doesn't appear in the help output on that version, but the CLI accepts it, and OpenAI's [CLI reference](https://learn.chatgpt.com/docs/developer-commands?surface=cli) lists it as the alias.

The useful thing about Codex is that it splits the problem into two dials. `--ask-for-approval` decides whether you get asked (`on-request` or `never`). `--sandbox` decides what a command can touch (`read-only`, `workspace-write` or `danger-full-access`). So this:

```bash
codex --ask-for-approval never --sandbox workspace-write
```

gives you zero prompts while keeping the OS sandbox around every command. That is the combination most people actually want from Codex YOLO mode — and `--yolo` throws away both dials at once. (`--full-auto` still exists as a deprecated compatibility flag; OpenAI recommends `--sandbox workspace-write` instead.)

## The prompt was never the safety feature

A boundary protects you on your worst day; a prompt only protects you on your most attentive one. Approval prompts assume a careful reviewer reading every call. By the third hour, nobody is that person.

We measure exactly this in Octomind's human time and energy report. It flags a **rubber-stamp** when a run changed 50 or more lines and your next message arrived in under 30% of the time it takes just to read the agent's text and reply. The [sessions documentation](/docs/usage/05-sessions) puts it plainly: that is "when fatigue ships bugs." A prompt you approve on reflex is a rubber-stamp with extra steps.

So the question isn't "prompts or no prompts." It's "what stops the bad call when I'm not looking?" Only something enforced below the model counts: the kernel, a container, a machine boundary, or a deny rule the runtime applies before the tool runs.

## I ran the same probe through four boundaries

I wanted numbers instead of vibes, so I wrote one shell probe and ran it through each boundary on my Mac on 2 October 2026. It checks four things: can it write inside the project, write into my home directory, read `~/.ssh`, and reach the network.

```bash
touch ./inside.txt && echo INSIDE_OK || echo INSIDE_BLOCKED
touch "$HOME/.yolo-probe-octomind" && echo HOME_WRITE_ALLOWED || echo HOME_WRITE_BLOCKED
wc -c "$HOME/.ssh/known_hosts" >/dev/null 2>&1 && echo SSH_READABLE || echo SSH_BLOCKED
curl -sS -m 5 -o /dev/null https://example.com && echo NET_OK || echo NET_BLOCKED
```

For Octomind, I handed the probe to an agent started with `octomind run --sandbox` and asked it to make exactly one shell call. This is what came back:

```text
INSIDE_OK
HOME_WRITE_BLOCKED
SSH_BLOCKED
NET_OK

stderr:
touch: /Users/dk/.yolo-probe-octomind: Operation not permitted
```

That session cost $0.018. Here are all four runs side by side:

| Boundary                                                | Write in project | Write in `$HOME` | Read `~/.ssh` | Network                     |
| ------------------------------------------------------- | ---------------- | ---------------- | ------------- | --------------------------- |
| None — plain shell, which is what YOLO mode gives       | allowed          | allowed          | allowed       | allowed                     |
| `octomind run --sandbox`                                | allowed          | blocked          | blocked       | allowed                     |
| `codex sandbox` (my config)                             | allowed          | blocked          | allowed       | allowed — my config opts in |
| `npx @anthropic-ai/sandbox-runtime` 0.0.78, no settings | blocked          | blocked          | allowed       | blocked                     |

Three things surprised me.

**No boundary blocks everything, and the gaps differ.** Octomind's macOS sandbox denies reads of credential directories (`~/.ssh`, `~/.aws`, `~/.gnupg` and a few more) but leaves the network open. Anthropic's runtime with no settings file blocks the network and every write — including the project itself, which is why the docs tell you to configure `~/.srt-settings.json` before launching Claude Code through it — yet it let the probe read `~/.ssh`. A boundary is a specific promise, not a general one. Read what yours promises.

**Boundaries break things, and that's how you know they're real.** Both Octomind runs logged the same failure on startup: the web-search MCP server I launch through `npx` died with `npm error code EPERM` on `~/.npm/_cacache`. Under `--sandbox`, npm can't write its cache in my home directory. The fix is to install that server ahead of time rather than through `npx`, not to widen the sandbox until the error goes away.

**Tool-level policy isn't an OS boundary.** My first attempt never reached the sandbox: octofs, our filesystem MCP server, rejected the whole command because it contained `ls`, and told the agent to use its `view` tool instead. That's a useful nudge toward cheaper tools. It is not something I'd bet my home directory on.

## Choose a Claude Code sandbox (or another boundary) that fits how you work

The right boundary depends on whether you're at the keyboard, how long the agent runs alone, and what it can reach. These are the options I'd consider, from lightest to strongest.

- **Claude Code's built-in sandbox (`/sandbox`).** The OS enforces it around Bash, PowerShell and Monitor commands, and network traffic goes through a proxy with an allowlist that starts empty. Reads stay open by default, `~/.ssh` included, until you add `denyRead` entries. And MCP servers and hooks still run unconstrained on the host, so Anthropic says it isn't sufficient for fully unattended runs. Great for fewer prompts while you're watching.
- **Anthropic's sandbox runtime.** `npx @anthropic-ai/sandbox-runtime claude` wraps the whole Claude Code process, MCP servers and hooks included. It's a beta research preview, and as my probe showed, you have to configure it before it lets you do real work.
- **A Claude Code dev container.** Anthropic publishes an [example dev container](https://code.claude.com/docs/en/devcontainer) with a default-deny firewall that runs Claude Code as a non-root user. This is the documented route for unattended `--dangerously-skip-permissions`.
- **Octomind `--sandbox` plus guards.** Writes are locked to the working directory by Seatbelt on macOS or Landlock on Linux, and the restriction is inherited by every child process, including shells and MCP servers. On macOS, credential directories are unreadable; on Linux they stay readable, because Landlock can't carve read exceptions out of a readable root. The network stays open on both. Add `[[guard]]` rules for commands you never want, and optionally the supervisor's [tool authorizer](/docs/usage/14-supervisor), which is off by default and checks each proposed call against your own instructions before it runs.
- **Hosted sandboxes like E2B or Daytona.** [E2B](https://e2b.dev/) runs each sandbox in a Firecracker microVM; [Daytona](https://github.com/daytonaio/daytona) offers isolated containers and VMs through an API. They're the right tool when you're building a product that executes model-written code, and the wrong one for your daily coding session.
- **A machine you can afford to lose.** This is what we built [Octomind Cloud](/blog/octomind-cloud-launch) on. Each machine runs under the sysbox runtime in its own user namespace, so root inside the machine is nobody on the host; the agent runs as a non-root user on a disk that can't grow past its quota; secrets go in write-only. Agents there run with no approval prompts by design. The worst case is a machine you rebuild, not a laptop you reinstall.

## What a boundary won't fix

A boundary limits where damage lands. It doesn't stop data leaving, and it doesn't protect what you put inside it.

If the network is open, the agent can send anything it can read to anywhere. Anthropic's own warning applies to every option above: "Any approach that allows network egress can still leak data the agent can read." Keep tokens and keys out of the box, or give it scoped ones you can revoke in a minute.

The project directory is writable by design, so commit before you hand over the keyboard — git is your undo button. And prompt injection doesn't care about your sandbox: a malicious README or issue comment can still steer the agent within whatever it's allowed to do. The [AI agent security checklist](/blog/ai-agent-security-checklist) covers those layers in order.

## The setup I'd actually use

For local work in Octomind, I run anything I haven't vetted with `octomind run --sandbox` and keep two guards in `.agents/guardrails.toml`:

```toml
[[guard]]
match   = "shell(command=^rm\\s+-rf?\\s+/)"
message = "Refusing rm -rf on root paths."

[[guard]]
match   = 'shell(command=git push.*(?:--force(?:\s|$)|-f(?:\s|$)))'
message = "Force push blocked. Use --force-with-lease and ask first."
```

A guard blocks the call before the executor runs, and the model gets a synthetic error it has to work around. These match command text, not shell semantics, so they cover the shapes I actually see rather than every possible way to delete a directory — that's the job of the sandbox underneath. The [guardrails reference](/docs/usage/18-guardrails) has the full matching language, and [Give your AI agent less power](/blog/lock-down-ai-agent-permissions) explains why I layer roles, sandbox and guards rather than picking one. If you want to watch each boundary fire for yourself, the [safe agent sandbox tutorial](/docs/use-cases/10-safe-agent-sandbox-and-guardrails) walks through a disposable project with a write probe.

For anything that runs for hours while I'm away, I don't sandbox my laptop harder. I move the work to a cloud machine, where no prompts is the default and the blast radius is a box built to be thrown away.

With Claude Code, I'd use `/sandbox` for everyday interactive work and the dev container whenever I reach for `--dangerously-skip-permissions`. With Codex, `--ask-for-approval never --sandbox workspace-write` covers most of what people want from `--yolo` without giving up the sandbox.

## FAQ

### Is --dangerously-skip-permissions safe?

Not on its own. It removes every prompt and gives the agent your full user permissions, with no protection against prompt injection. It becomes reasonable inside an isolated environment — a dev container, VM, sandbox runtime or disposable cloud machine — running as a non-root user, ideally with network egress restricted and no long-lived credentials inside.

### What is the Claude dangerously skip permissions command?

Run `claude --dangerously-skip-permissions`, or the equivalent `claude --permission-mode bypassPermissions`. For an unattended one-shot run, use `claude -p "your task" --dangerously-skip-permissions`. To keep the mode available without starting in it, launch with `--allow-dangerously-skip-permissions` and switch with Shift+Tab when you need it.

### Does Codex have a dangerously-skip-permissions flag?

Not under that name. Codex uses `--dangerously-bypass-approvals-and-sandbox`, aliased as `--yolo`, which removes both approvals and the sandbox. If you only want to stop the prompts, use `--ask-for-approval never --sandbox workspace-write`, which keeps commands inside Codex's OS sandbox.

### What is the Claude Code sandbox?

It's the built-in Claude sandbox: an OS-enforced boundary around the shell commands Claude Code runs, opened with `/sandbox`. It restricts which files Bash, PowerShell and Monitor commands can write and which network domains they can reach. MCP servers and hooks aren't covered, so for unattended runs Anthropic recommends a dev container, VM or the sandbox runtime.

## The prompts were a placeholder

Permission prompts were a stand-in for a boundary nobody had built yet. Build the boundary once — a sandbox, a container, a machine you can throw away — and you get your afternoon back without betting your home directory on it. If you'd rather not build the box yourself, that's what [Octomind Cloud](/cloud) is for.