--dangerously-skip-permissions is a Claude Code flag that turns off approval prompts, so the agent reads files, changes them and runs commands with the developer's own access and nobody checks first. Any developer can add it without asking you. Your policy should be simple: allow it only in isolated containers, block it on laptops through managed settings, and check that the block is really in place on every machine.
Anthropic's documentation puts it plainly: bypass mode "offers no protection against prompt injection or unintended actions." If your developers use Claude Code, you need to know whether this is on, and most security teams can't answer that today. Everything below comes from Claude Code's documentation as of October 2026.
What your company is exposed to
The flag starts Claude Code in bypass mode. For a security team, three things change:
- Nobody approves anything. The agent acts immediately, using the same access as the developer. That usually means source code, cloud credentials, SSH keys and production tooling.
- Protected files open up. Other modes guard
.git,.claude,.gitconfig,.bashrc,.zshrc,.npmrcand.mcp.json. In bypass mode the agent can write to them, so a bad change can keep running long after the session ends. - Hostile content gets a straight path to action. An agent reads web pages, tickets and dependencies all day. If one of them carries hidden instructions, there's no approval step left to stop them.
It's also easy to turn on for good. The first time a developer uses the flag, they accept one warning, and Claude Code saves that choice to their settings. Scripts running with claude -p never show the warning. Once it's in a developer's shell alias or a scheduled job, it stays there.
What this looks like as an incident
Here's an example, made up but ordinary. A developer wants a long refactor finished over lunch, so they start Claude Code with the flag on their laptop. Partway through, Claude reads a GitHub issue for context. Someone has hidden an instruction in it, telling any agent reading it to add a line to ~/.zshrc and post ~/.aws/credentials to an outside address.
With no approval step, the credential leaves and the startup file changes. The refactor still finishes, and the developer comes back to passing tests. You'd find out when that key gets used somewhere it shouldn't be, and at that point you'd have to work out which laptop it came from and what else the agent touched. We walk through this kind of attack in what a prompt injection looks like on a laptop.
Join the launch list and see which of your machines have this turned on. You'll be first in when ZYBE opens.
What still holds in bypass mode
A few controls survive, and they're useful to know when you write your policy:
| Control | In bypass mode |
|---|---|
| Deny rules | Still block |
| Explicit ask rules | Still prompt |
Deleting critical paths such as / or a home directory |
Still prompts, unless a separate override is set |
| Running as root or with sudo | Refused on Linux and macOS |
A repo's own .claude/settings.json |
Can't turn bypass mode on |
The last row is good news: a cloned repo can't switch this on through its project settings. It can only come from the developer's own settings, a launch flag or your managed settings. Deny rules help too, but they aren't a boundary. They cover Claude's file tools and the commands it recognises, and a script the agent writes itself can get around them.
Why the sandbox doesn't solve it
Your developers may tell you it's fine because they run /sandbox. The sandbox is worth having, but it doesn't make this flag safe on a laptop:
- It can read credentials. By default, sandboxed commands can read most of the machine, including
~/.sshand~/.aws/credentials. - Its network limits go soft. Normally commands only reach domains you've listed. In bypass mode, unlisted hosts are allowed without a prompt.
- Its escape hatch opens without asking. If a command fails in the sandbox, Claude can retry it outside, and bypass mode doesn't ask anyone.
- It only covers shell commands. File tools, MCP servers and hooks run outside it.
- It can quietly not run. If a dependency is missing, commands run without it unless you set
sandbox.failIfUnavailable. It's off by default and doesn't run on native Windows.
Together, the first two points mean a command can read a credential and send it to a host nobody approved, without a single prompt.
The policy to set
| Where the agent runs | What your policy should say |
|---|---|
| Developer laptops | Bypass mode blocked. Auto mode or manual mode |
| Throwaway containers with no real credentials and limited network | Bypass mode allowed |
| CI and scripts | dontAsk mode with a short list of allowed tools |
Developers mostly reach for this flag because the prompts slow them down, so give them another way to get that speed. Auto mode runs without routine prompts, and a separate model checks each action first, blocking things like curl | bash, force pushes, terraform destroy and production deploys. The documentation says it "does not guarantee safety", but it's far better than no checks. From Claude Code v2.1.283 it's the default starting mode in the terminal and VS Code.
How to enforce it
Put this in managed settings, which developers can't override, and roll it out through your device management tool:
{
"permissions": {
"disableBypassPermissionsMode": "disable"
},
"sandbox": {
"enabled": true,
"failIfUnavailable": true,
"allowUnsandboxedCommands": false
}
}
The first block turns bypass mode off. The second is the managed sandbox configuration the documentation recommends. Try the sandbox block with a few developers before rolling it out everywhere, because some tools won't work inside it. Our guide to Claude Code permissions explains how managed settings rank against the other settings files, and our Claude Code security guide covers the rest of the baseline.
Why a policy isn't enough
A managed file only protects the machines it reached. It doesn't tell you which laptops missed the rollout, who started every session in bypass mode before you shipped it, or who runs other agents with the same kind of switch, like Codex or Cursor. An auditor will ask how you know the control is working, and "we pushed a file" doesn't answer that. With three hundred developers, you can't get the answer by asking around.
How ZYBE handles this
ZYBE finds every AI agent on every endpoint and shows how each one is set up, in one console. A machine whose settings start Claude Code in bypass mode raises Agent acts without asking, naming the machine and the agent. An agent that runs a command with --dangerously-skip-permissions, or edits an agent's settings file, raises Agent safety control turned off when it happens. Both are recorded by default, and you can set the second one to ask a person or block the action.
Bypass mode also raises that agent's risk score, so a laptop with credentials in reach and an agent that never asks stands out from the rest of your fleet. That tells you which machines to fix first, and gives you dated evidence for the auditor.
Join the launch list and be first to see this across your own endpoints
Frequently asked questions
What is the difference between --dangerously-skip-permissions and --allow-dangerously-skip-permissions? The first starts the session in bypass mode straight away. The second only adds bypass mode to the Shift+Tab cycle, so the session starts normally and someone has to switch into it later.
Why does --dangerously-skip-permissions fail with a root or sudo error? On Linux and macOS, Claude Code refuses to start in bypass mode as root or under sudo, and prints "--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons". Run it as a non-root user. The check is skipped inside a recognized sandbox, and the official dev container already runs Claude Code as a non-root user.
Can a repository turn on bypass mode by itself? No. A defaultMode of bypassPermissions in .claude/settings.json or .claude/settings.local.json does not take effect, and the session starts in Manual mode instead. It only works from user settings, the --settings flag or managed settings, so a cloned repo cannot switch it on through those two files.
Does --dangerously-skip-permissions work in Claude Code cloud sessions? No. Cloud sessions do not honor a defaultMode of bypassPermissions, so setting it there changes nothing.