Blog
Claude Code yolo mode: what --dangerously-skip-permissions actually skips
Nobody enables it because they stopped caring. They enable it because approving the fourteenth file edit is not review, it is clicking, and the clicking was not making anything safer.
--dangerously-skip-permissions turns off Claude Code's per-action approval prompts, so it edits files, runs commands and calls tools without stopping to ask. It does not widen what Claude Code can reach: the agent already had your filesystem, your environment and your network, because it runs in your shell with your permissions. The flag removes the human in the loop, not a technical boundary. That is why the useful response is not to leave it off, but to make the things you were approving for cheap to get wrong: put the agent on its own worktree, bound the folders it can touch, and make sure the credentials in reach are ones it can use without ever holding.
What the flag does
Claude Code asks before it acts. Editing a file, running a command, using a tool: each one can stop for a yes. The flag, commonly called yolo mode, turns those prompts off for the session.
What it does not do is grant anything. Before the flag, Claude Code could already read every file your user can read, run every command your shell can run and reach every host your machine can reach. It asked first. The permission system is a review step, not a fence, and skipping it removes the review, not a wall.
This matters for how you compensate. If the flag opened a door, the answer would be to close the door. It did not, so the answer is to make the room smaller.
Why people turn it on
Approval fatigue is real and it is not laziness. A long task generates dozens of prompts, most of them for actions you would obviously allow, and the fourteenth one is not getting the attention the first one did. A review step you have stopped reading is worse than no review step, because it feels like oversight while providing none.
There is a second cost that is easier to miss. Every prompt is a place the agent stops and you have to be there. That is what makes unattended work impossible, and unattended work is most of the value of an agent. You cannot go to lunch while something asks you fourteen questions.
So the real question is not whether to skip permissions. It is what has to be true before skipping them is a reasonable thing to do.
The three things that make it reasonable
Each of these removes a category of consequence rather than adding a prompt.
- Its own working tree. Put the session on a git worktree so a bad edit lands on a branch in a directory you can delete, not on the code you are working in. Claude Code ships --worktree for this, and Cursor has /worktree.
- Bounded folders. Confine what the agent can read and write, so a delete that is correct inside the repository and wrong one directory up hits a wall. macOS does this in the kernel through Seatbelt, and Claude Code and Codex both ship a sandbox of their own.
- Keys it can use without holding. This is the one that is usually missed. An agent running without prompts, in a shell with a token in the environment or a .env in the tree, can send that value anywhere, and no approval prompt was protecting it anyway. The value has to stop being readable, not the actions.
Why the credential half is the half that matters
The first two make mistakes cheap. A bad edit is on a branch. A bad delete hits a boundary. Both are recoverable, and recoverable is the whole point.
A credential is the exception, because it is the one thing that does not get better when you notice. A key that has been read, printed into a transcript, or committed into a history has already left, and the only remedy is rotation. GitGuardian's State of Secrets Sprawl 2026 found that code written with an agent leaks credentials at roughly twice the rate of code written without one, and that is with everyone's approval prompts on.
Note what that implies about trust. An agent you trust completely still runs git add with a .env in the tree, still echoes an environment variable into a log while debugging, and still sends whatever it read upstream as context. Competence is not the variable, and neither is the flag.
How this works in Forkbench
Forkbench is a Mac app for running coding agents, and it runs the same claude binary you run today, with your flags, your hooks and your MCP servers untouched. It does not add a second approval layer, because a second layer of the thing people are turning off is not an answer.
It changes what the flag can cost. A key in the Vault is used by the command that needs it and never handed to the agent, so it is not in the prompt, the command line or the transcript, whether or not you are approving actions. A Thread can be locked to a set of folders, enforced by the kernel and inherited by every process the shell starts. A session can take its own worktree in one click. And a task the agent reports finished is a report, not a completion, so the human is still in the loop at the end, where judgement is worth something, instead of fourteen times in the middle where it is not.
The limit, stated plainly: nothing here stops an agent from reading a .env file that is already sitting in the project, because it has the same filesystem access you do until you lock the folders. Move the key into the Vault and there is nothing in that file worth reading.
Related: How to sandbox an AI coding agent on macOS
Frequently asked
Is --dangerously-skip-permissions safe?
It is exactly as safe as the environment you run it in, because it grants nothing. Claude Code already has your files, your environment and your network, since it runs in your shell as you. The flag removes the human review step. Make that acceptable by putting the session on its own worktree, bounding the folders it can touch, and keeping credentials out of its reach, and the prompts you removed were not the thing protecting you anyway.
What is yolo mode in Claude Code?
Yolo mode is the common name for running Claude Code with --dangerously-skip-permissions, which turns off the per-action approval prompts so the agent edits, runs and calls tools without stopping to ask. It is popular for long or unattended tasks, where stopping fourteen times means you have to sit there, and where the fourteenth approval gets far less attention than the first.
Does yolo mode let Claude Code access more of my machine?
No. The scope is the same with the flag and without it. Claude Code runs in your shell with your user's permissions, so it can already read what you can read and run what you can run. The approval prompt is a checkpoint in front of that access, not a limit on it, and skipping it changes who is watching rather than what is reachable.
How do I run Claude Code unattended without giving it my API keys?
Keep the value out of the process. A broker can run the command that needs the credential and hand back only the result, so the key never enters the prompt, the command line or the transcript, which is what Forkbench's Vault does. Bind the key to a destination and the same key aimed anywhere else is refused. What that does not do is inspect what a command you authorised does with what it was given, so treat it as containment rather than a guarantee.
Is a sandbox better than approval prompts?
They solve different halves. Prompts put a person in front of each action, which stops being review once there are dozens of them. A sandbox makes the action cheap to get wrong whether or not anyone is watching, which is what lets an agent run unattended. The combination that works in practice is a narrow sandbox plus a human decision at the end, on whether the finished work is accepted, rather than a human decision before every step.