Guide · Claude Code permission modes

Is it safe to use claude --dangerously-skip-permissions?

Updated 2026-10-31

Only inside an isolated machine. --dangerously-skip-permissions starts Claude Code in bypassPermissions mode, which runs tool calls without asking, and Anthropic's documentation says to use it only in containers, VMs or dev containers without internet access, because it offers no protection against prompt injection or unintended actions. On your own user account it can change or delete anything you can.

01Steps

Try a mode that still asks first. acceptEdits lets Claude Code edit files without prompting but still asks before shell commands. Anthropic's auto mode goes further, with a classifier reviewing each action; its docs say it reduces prompts but does not guarantee safety.
Add deny rules, which hold in every mode. Deny rules block in every permission mode, including bypassPermissions. Put them in the project's .claude/settings.json; .claudeignore files have no effect.
.claude/settings.json
```
{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./secrets/**)"]
  }
}
```
Install kosa8 and start its daemon. kosa8 runs sandboxes on an Apple silicon Mac or an x86-64 Linux machine with KVM. kosa8 doctor reports anything missing.
Keep the API key on your side and preview the plan. Set the key in your own shell only. The dry run prints what the sandbox will see, reach and hold, and starts nothing; look for the line saying the sandbox holds a placeholder.
Run Claude Code in its own microVM. Commit first, then start the claude kit with -w naming the one folder Claude Code may see. The sandbox is removed when Claude Code exits; the folder keeps its changes.
Review what it did and approve held calls. Every brokered request and every tool call is in a hash-chained audit log. A force push or a package publish waits in a queue for a person.

02What does --dangerously-skip-permissions actually turn off?

It starts Claude Code in bypassPermissions mode, the same as --permission-mode bypassPermissions, so tool calls run without prompts, including writes to protected paths such as .git, .claude and shell startup files. Deny rules still block, a few actions such as a recognised rm of a critical path still prompt, and on Linux and macOS Claude Code refuses the flag when run as root or under sudo outside a sandbox it recognises.

Allow rules have no effect in this mode, because everything is already allowed. The first interactive run shows a warning dialog you must accept. Teams can switch the mode off for everyone with permissions.disableBypassPermissionsMode set to "disable" in managed settings.

What the flag does not change is where Claude Code runs. Without a sandbox it acts as your user, with your home directory, your SSH keys, your cloud credentials and your network.

03Does a devcontainer make --dangerously-skip-permissions safe?

It narrows the damage but does not remove it. Anthropic's dev container documentation says that with --dangerously-skip-permissions a dev container does not prevent a malicious project from exfiltrating anything accessible inside the container, including the Claude Code credentials in ~/.claude, and that Claude can still modify any file in the bind-mounted workspace. It recommends pairing the flag with an egress firewall and using only trusted repositories.

The reference container's init-firewall.sh limits outbound traffic to the destinations the script allows, and needs the NET_ADMIN and NET_RAW capabilities to do it. A container also shares the host's kernel, so a kernel bug reached from inside is a bug in your machine's kernel.

04Claude Code deleted my home directory: how do I stop it happening again?

Do not run bypass mode as your own user. Put a machine boundary around it that decides what Claude Code can reach whatever it decides to run: in a kosa8 microVM it sees one project folder, its network is closed except for the hosts its kit names, and it holds a placeholder instead of your Anthropic API key. Your home directory is not shared into the VM, so nothing inside can delete it.

Its own kernel. Each sandbox is a virtual machine with a Linux kernel of its own, on Apple's Virtualization framework or on KVM with Cloud Hypervisor.
Keys outside. A broker on your computer adds the real key to requests bound for api.anthropic.com. A request to any host not on the kit's list is refused before it leaves your computer, and recorded.
Checked tool calls. With the claude kit, kosa8 checks each tool call against its rules before it runs: a download piped into a shell is refused, and a force push waits for kosa8 mcp approve.
The shared folder is still shared. Claude Code can change anything in it, including .git and any .env file. Share a project, not your home directory, and commit first.

05Can I pass --dangerously-skip-permissions through kosa8?

Anything after the kit name on the kosa8 agent run command line is handed to Claude Code, so the flag can be passed. kosa8's docs do not cover this combination, though, and the assistant runs as root inside its VM, which Claude Code refuses for this flag unless it recognises the sandbox it is in.

If Claude Code refuses, acceptEdits or auto mode inside the VM gives you far fewer prompts without the flag, and the VM boundary and kosa8's tool-call checks apply in every mode.

06Other options

Claude Code's built-in /sandbox wraps shell commands in Seatbelt on macOS or bubblewrap on Linux. It fits day-to-day work in acceptEdits or auto mode; set allowUnsandboxedCommands to false and deny reads of credential files.
A dev container fits a team that already standardises on one. Anthropic's reference container adds an egress firewall and runs Claude Code as a non-root user, so the flag is accepted there.
Docker Sandboxes runs each agent in its own microVM with its own Linux kernel, from Docker's tooling.
A full VM in UTM or Lima fits when you want a general-purpose guest you manage yourself.
Hosted sandboxes such as E2B, Daytona or Modal fit when the agent should run in the cloud rather than on your machine.