Run Claude Code with --dangerously-skip-permissions safely

Run Claude Code with --dangerously-skip-permissions only inside a container, a VM, or Anthropic's sandbox runtime, with nothing reachable that you can't afford to lose: no SSH keys or cloud logins, a GitHub token for one repository, and outbound traffic limited to an allowlist.

Anthropic's docs: “Always run --dangerously-skip-permissions sessions inside a container, a VM, or the sandbox runtime.” That sentence was read on November 8, 2026, for Claude Code 2.1.319. Four setups give you the wall it asks for. On your own computer: Anthropic's sandbox runtime (srt claude), Anthropic's dev container with its firewall, or Docker Sandboxes, which puts the agent in a microVM. Off it: a cloud VM you throw away after the task. Pick by how strong the wall is, how many agents you want running at once, and whether your computer has to stay on while they work. Claude Code's cloud sessions are a fifth way in, but they don't offer bypass mode at all.

Anthropic's pages on sandbox environments, permission modes, sandboxing, dev containers, authentication, and cloud sessions, OpenAI's Codex docs on approvals, sign-in, and Codex Cloud, Docker's Sandboxes docs, and each vendor's pricing page were read on November 8, 2026, between 09:25 and 09:50 UTC. Versions are the latest on npm that day: Claude Code 2.1.319, published November 6, 2026, and Codex CLI 0.167.0. Docker's sbx CLI was at v0.51.0, released November 3, 2026. claude --help (2.1.319) and codex --help (0.166.0) were run for this post. Docker Sandboxes and tmux weren't installed on the machine that wrote it, so their commands are quoted from Docker's docs and the tmux wiki. No session was run with the flag, and the cloud VM steps weren't run end to end.

What --dangerously-skip-permissions turns off

claude --help in 2.1.319 describes the flag in one line: “Bypass all permission checks. Recommended only for sandboxes with no internet access.” Anthropic's permission modes page says it's equivalent to claude --permission-mode bypassPermissions, a mode that “disables permission prompts and safety checks so tool calls execute immediately, including writes to protected paths.” In the page's table of modes, its row says “Everything” runs without asking, and that the mode is best for “Isolated containers and VMs only.”

A few guards stay on in bypass mode:

• Deny rules. “Deny rules block in every mode, including bypassPermissions.” So does a PreToolUse hook that denies a call, as in Claude Code hooks: how to block a command before it runs.
• Critical paths. An rm or rmdir aimed at the filesystem root, your home directory, or your working directory still prompts or gets refused. Anthropic adds: “The check can miss some commands, so it doesn't replace an operating-system control such as sandboxing.”
• Root. On Linux and macOS, Claude Code won't start in this mode as root or under sudo. It prints --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons, and “The check is skipped automatically inside a recognized sandbox.”
• An admin switch. permissions.disableBypassPermissionsMode set to "disable" in managed settings blocks the mode for everyone in an organization.

What the mode doesn't do is defend you. In Anthropic's words, “bypassPermissions offers no protection against prompt injection or unintended actions.”

Codex has its own flags for the same choice:

From claude --help and codex --help, run November 8, 2026, and from Anthropic's permission modes and sandboxing pages and OpenAI's agent approvals and security page, read the same day.

Claude Code's built-in sandbox, the one /sandbox turns on, isn't enough by itself. “The sandbox covers shell commands only. Claude's file tools, MCP servers, and hooks run outside it.” By default those commands can read “Most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials.” In bypass mode, a command that fails inside the sandbox may be retried outside it, and that retry “runs without a prompt” unless "allowUnsandboxedCommands": false turns the retry off. Bypass mode also lets a sandboxed command reach a host outside your allowed domains, with no prompt, unless strictAllowlist is on. Anthropic's own verdict: the sandboxed Bash tool “on its own constrains only shell commands, so it is not sufficient for fully unattended runs.” Auto mode isn't a wall either: “The classifier is a per-action control, not an isolation boundary.”

What goes wrong without a wall

Each of these has a public record:

• Deleted files. In GitHub issue #10077 (October 21, 2025, Claude Code 2.0.22 on WSL2), a user wrote that “Claude Code executed a destructive recursive delete command that successfully deleted all user files in my home directory.” In #12637 (November 28, 2025, 2.0.55 on macOS), Claude “created a directory named ~ in error, and then ran rm -rf * in the parent directory, which the shell expanded to include my home directory.” Neither report says bypass mode was on. They show what one command does when nothing outside Claude Code stops it.
• Stolen logins. Anthropic's dev container page warns that with the flag, “dev containers do not prevent a malicious project from exfiltrating anything accessible inside the container, including the Claude Code credentials stored in ~/.claude.” OpenAI writes the same about Codex: a malicious project “can exfiltrate anything available inside the devcontainer, including Codex credentials.”
• Prompt injection. A file the agent reads can give it orders. In Forever Security's research, published October 22, 2026, a planted CLAUDE.md leaked Claude Code's login token “about 50% of the time.” The details are in AGENTS.md in Downloads can hijack Codex and Claude Code.
• Malware that drives the agent. Malicious nx versions published to npm on August 26, 2025 held “code that scans the file system, collects credentials, and posts them to GitHub as a repo under user's accounts,” in the words of Nx's advisory. StepSecurity found the malware starting claude with ['--dangerously-skip-permissions', '-p', PROMPT], a prompt that asked it to search the disk for keys and wallets and list their paths in /tmp/inventory.txt. On a machine with nothing to find, that search comes back empty.

A wall makes the damage smaller; it doesn't make the risk zero. Anthropic: “Any approach that allows network egress can still leak data the agent can read, and any approach that mounts your project directory writable can still modify that code.” Its checklist for any container is three questions: “review what is mounted writable, what credentials and tokens are reachable inside it, and what the network egress policy allows.”

13 setups compared

Every row comes from the vendor's own docs and pricing page, read November 8, 2026. Prices exclude tax. The hourly figures for a 4 vCPU, 8 GB machine are this post's arithmetic from each vendor's per-unit rates.

How strong the wall is. Anthropic ranks a VM first: “A dedicated virtual machine provides the strongest separation, with its own kernel and, in cloud or microVM deployments, its own virtualized hardware.” The /sandbox and srt rows run on your computer's kernel next to your files. A container shares your computer's kernel. Docker Sandboxes, Sprites, and the VM rows each get their own; Daytona's container class doesn't.

Whether your computer stays on. The local rows stop when your computer sleeps. A cloud session “keeps running after you close your laptop,” a Codex Cloud task “can keep working while your computer is asleep,” and a rented VM runs until you stop it or its own timer does.

Network defaults differ more than isolation does. Docker's local sandboxes block all outbound TCP “unless an explicit rule allows the destination.” exe.dev, Sprites, and E2B start open. On boat.dev and a plain VPS, the firewall is yours to write.

Set it up on your computer with Docker Sandboxes

Docker's install page asks for macOS 14 or later on Apple silicon, Windows 11 with Windows Hypervisor Platform turned on, or Ubuntu 24.04 or later with KVM. These steps are quoted from Docker's docs, read November 8, 2026, and weren't run for this post.

1. Install sbx and sign in to Docker. On a Mac:

brew trust docker/tap
brew install docker/tap/sbx
sbx login

On Windows, Docker's command is winget install -h Docker.sbx. On Ubuntu, curl -fsSL https://get.docker.com | sudo SBX=1 sh installs Docker Engine and sbx together.

2. Set the network policy before the first run, then read it.

sbx policy init balanced
sbx policy ls

Balanced lets common development services through and blocks other destinations unless you approve them. Locked Down needs an allow rule for every destination. Docker warns that “The default allowed domains include broad wildcards,” so remove the entries you don't need.

3. Start Claude Code in a private clone of your repository.

cd ~/my-project
sbx run --clone claude .

Before it edits, ask Claude to work on a new branch and commit its changes: git fetch in step 4 brings back commits only, and Claude doesn't commit unless asked. Fetch while the sandbox is still running.

Without extra arguments, the sandbox runs claude --dangerously-skip-permissions. Docker's FAQ explains why: “The sandbox itself is the safety boundary.” Type /login inside to use your Claude subscription, or store an API key on your computer with sbx secret set anthropic.

--clone matters. Plain sbx run claude mounts your working tree read-write, and “Edits the agent makes to your project appear in your working tree as it writes them.” That includes files that run later: “Git hooks, CI configuration, IDE task configs, AI project configuration and settings, Makefile, package.json scripts.” And “Git hooks live inside .git/ and do not appear in git diff output.” In clone mode, “your repository is mounted read-only and the agent works on a private clone.”

4. Review the branch from your computer, with the commands from Docker's Claude Code page:

git fetch sandbox-<sandbox-name>
git diff main..sandbox-<sandbox-name>/<branch>

When you're done, sbx rm my-sandbox deletes everything inside it, the in-sandbox clone included, so fetch what you want to keep first. For a sandbox you started without --name, sbx ls lists the names.

Or Anthropic's dev container

Anthropic's reference container in the anthropics/claude-code repository combines the CLI, an egress firewall, persistent volumes, and a Zsh shell. Install VS Code and the Dev Containers extension, clone that repository, run Dev Containers: Reopen in Container, then run claude in the container's terminal. For your own project, copy its .devcontainer/ folder into your repository.

It runs Claude Code as the non-root node user, so the flag works: “Because the container runs Claude Code as a non-root user and confines command execution to the container, you can pass --dangerously-skip-permissions for unattended operation.” Its init-firewall.sh runs at every start, sets every iptables policy to DROP, and lets through registry.npmjs.org, api.anthropic.com, sentry.io, statsig.com, the VS Code marketplace and update hosts, GitHub's web, API, and git address ranges, and the host's own network. It then checks that https://example.com is blocked and https://api.github.com reachable.

Read it before you trust it. The same script lets any outbound connection to port 22 and DNS on UDP port 53 through, plus the host's /24 network, and all of GitHub is open, which Anthropic itself flags: “Allowing broad domains such as github.com can create paths for data exfiltration.” Your project is bind-mounted, so “Claude can still modify any file in the bind-mounted workspace, which appears directly on your host.”

Set it up on a cloud VM

A VM you rent for the task, and delete after it, is the setup Anthropic ranks strongest. It also keeps running when your laptop is closed. The recipe is the same on exe.dev, Fly.io Sprites, boat.dev, or a plain VPS:

1. Start with a machine that holds nothing. Don't copy ~/.ssh, ~/.aws, ~/.config/gcloud, or a .env file with live secrets onto it, and don't sign in to a cloud provider's CLI there. You log in to the VM with your SSH key; the VM never needs one. Anthropic's advice for containers applies: “Avoid mounting host secrets such as ~/.ssh or cloud credential files into the container; prefer repository-scoped or short-lived tokens.” If the image logs you in as root, add a normal user first, because the flag refuses root.

2. Install Claude Code with Anthropic's installer, then check it:

curl -fsSL https://claude.ai/install.sh | bash
claude --version

3. Sign in without a browser. On your own computer, claude setup-token prints a one-year token. On the VM, set it as Anthropic's docs show: export CLAUDE_CODE_OAUTH_TOKEN=your-token. It needs a Pro, Max, Ultra, Team, or Enterprise plan, and it “can only make model requests,” so it can't start Remote Control sessions or fetch claude.ai connectors. The other way is /login on the VM: open the sign-in URL it gives you in your own browser, and if the browser shows a code, paste it at the Paste code here if prompted prompt. For Codex, codex login --device-auth signs in with a one-time code; turn on device code login in your ChatGPT security settings first.

4. Give it one repository. Create a fine-grained personal access token on GitHub. Under Repository access, choose Only select repositories and pick the one repository. Grant contents and pull requests read and write, and set an expiration; GitHub says “we highly recommend adding an expiration.” GitHub's documented URL parameters can fill the form for you, minus the repository choice:

https://github.com/settings/personal-access-tokens/new?name=agent-vm&expires_in=7&contents=write&pull_requests=write

Leave out the workflows permission, so the agent can't change your GitHub Actions files. On the VM, put the token in GH_TOKEN; gh's help says “Favour setting GH_TOKEN for fine-grained personal access token usage.” Then let git use it and clone (gh 2.101.0 help; not run for this post):

gh auth setup-git
gh repo clone OWNER/REPO

The token can push to any branch of that repository. A GitHub ruleset that protects main makes a pull request the only way in. Anthropic says the same of its own cloud sessions, whose proxy “doesn't limit which branches a push can update. To do that, use branch protection rules or rulesets on GitHub.”

5. Limit where it can connect. Use the provider's egress control where there is one: exe.dev's ssh exe.dev egress my-vm integrations blocks the public internet, Anthropic's API included, and leaves only exe.dev's own integration endpoints, so attach exe.dev's LLM and GitHub integrations or the agent can't work; Sprites take a DNS allowlist through their API; Daytona and E2B take allowlists. Elsewhere, run Claude Code through Anthropic's sandbox runtime on the VM. “By default the runtime denies network access,” so you allow api.anthropic.com, claude.ai, and platform.claude.com (which sign-in and token refresh need), GitHub for the push, and your package registry, and allow writes to your project, ~/.claude, ~/.claude.json, and /tmp. On Linux the runtime needs bubblewrap, socat, and ripgrep. Install it with npm install -g @anthropic-ai/sandbox-runtime and put your settings in ~/.srt-settings.json. The runtime grants writes only to paths that already exist, so on a fresh VM run Anthropic's line mkdir -p ~/.claude && { [ -f ~/.claude.json ] || echo '{}' > ~/.claude.json; } first, then start with srt claude. The dev container's init-firewall.sh is written for a container: on a VM you reach over SSH, its INPUT policy drops new connections from outside the host's /24, your next login included.

6. Run it in tmux, so it survives your logout. The tmux wiki's commands: tmux new -smysession starts a session, C-b d detaches, and tmux attach -tmysession comes back. Start claude --dangerously-skip-permissions inside it. Claude Code also has a --tmux flag, which, in its help's words, will “Create a tmux session for the worktree (requires --worktree).”

7. Bring the work back as a pull request. Ask Claude to commit on a branch, push, and open a pull request, and review it as you would a stranger's. Then delete the VM and the GitHub token.

Keep credentials off the machine

Anything the agent's user can read, a bypass-mode session can send out. This is where each login ends up:

From Anthropic's authentication page, OpenAI's authentication page, and Docker's Sandboxes docs, read November 8, 2026.

Can you use your Claude subscription inside a Docker sandbox? Locally, yes. Docker's get-started page: “For Claude Code with a Claude subscription (Max, Team, or Enterprise), no upfront setup is needed — use the /login command inside the sandbox to sign in with OAuth.” Docker's tutorial says only “Claude Code with a Claude subscription,” and neither page names Pro. Docker's cloud sandboxes are different: “For Claude Code, use an Anthropic API key.” Claude Code's own cloud sessions run on the subscription with no key.

A proxy hides a token's value, not its reach. Docker's proxy “injects authentication headers into outbound HTTP requests,” so a request the agent sends still carries your token. The token's scope is what limits the damage. Docker's example stores your gh login's token with sbx secret set github --command 'gh auth token'; that token reaches everything your gh login does. A fine-grained token for one repository reaches one.

Running several at once: worktrees or separate machines

claude --worktree feature-auth starts a session in .claude/worktrees/feature-auth/, on a new branch named worktree-feature-auth. In Anthropic's words, worktrees “isolate file edits.” That's all they isolate. Every session on the machine runs as the same user, so a bypass-mode session that goes wrong can reach the other worktrees, the logins, and the network. Docker gives the same advice for several sessions in one sandbox: “each background session needs a separate worktree or clone. Branches alone don't isolate edits in one working directory.”

Separate machines cost more as you add them. Claude Code's cloud sessions “share rate limits with all other Claude and Claude Code usage within your account.” OpenAI says Codex “Cloud tasks may use more of your allowance than local messages.” On Sprites, E2B, or Daytona, 3 busy agents at about $0.33 an hour each come to about $1 an hour; on boat.dev, about $0.11. For subagents inside one session, which share its sandbox, see Codex vs Claude Code subagents.

When a sandboxed run ends with a single HTML file, such as a page it built, drop it into Convika's upload box to open it on a phone or send it as a link. The no-sign-up preview runs no scripts: how to preview an HTML file from Codex or Claude Code.

Frequently asked questions

Is --dangerously-skip-permissions safe in Docker?

Safer, not safe. Anthropic's dev container is built for it: a non-root user, a default-deny firewall, and no host secrets mounted. Two risks remain. Your project is bind-mounted, so changes land on your computer, and anything inside the container, the Claude login in ~/.claude included, can leave through whatever the firewall allows. A container also shares your computer's kernel. Docker Sandboxes and VMs give the agent a kernel of its own.

Claude Code sandbox vs Docker sandbox: what's the difference?

Claude Code's /sandbox restricts shell commands on your own computer with the operating system's sandbox, Seatbelt on macOS and bubblewrap on Linux. Claude's file tools, MCP servers, and hooks run outside it, and by default it can read most of your files. Docker Sandboxes put the whole agent in a microVM with a “separate kernel per sandbox,” its own Docker daemon, and credentials that stay on your computer. Anthropic calls the built-in sandbox “not sufficient for fully unattended runs.”

Can I use my Claude subscription inside a Docker sandbox?

Yes, in a local Docker sandbox: run /login inside it. Docker names Max, Team, and Enterprise, and says the session token stays on your computer. Docker's cloud sandboxes take an Anthropic API key instead. In a plain container or VM, /login stores the login inside it, at ~/.claude/.credentials.json, or you can pass a one-year token from claude setup-token.

Does Claude Code on the web need --dangerously-skip-permissions?

No, and it can't use it. Cloud sessions offer “Accept edits, Plan, and Auto,” and Anthropic's permission modes page says “Bypass permissions isn't available.” A repository's settings can't switch it on either: cloud sessions “don't honor defaultMode: "bypassPermissions".” The session runs in an Anthropic-managed VM, and file edits are approved without asking in every mode.

Can the agent escape the sandbox?

It can, in two ways. By design: in bypass mode, Claude Code's own sandbox lets a failed command retry outside it, and that retry “runs without a prompt” unless "allowUnsandboxedCommands": false is set. Its network allowlist is open in bypass mode too, unless strictAllowlist is set. By bug: Claude Code 2.1.319, published November 6, 2026, lists “Fixed a sandbox escape when creating a worktree.” A microVM or VM is a separate layer, and Docker still assumes the worst inside its own: “The agent has full control inside the VM, including sudo access.” Keep Claude Code updated, and keep secrets off the machine entirely.

Is auto mode a safer choice than --dangerously-skip-permissions?

It keeps a check on each action: a classifier reviews it before it runs. Anthropic says “The classifier is a per-action control, not an isolation boundary,” and still recommends an isolation boundary for unattended runs, though it's “not required the way it is for --dangerously-skip-permissions.” For runs you don't watch, auto mode inside a sandbox gives you both.

What is Codex's version of --dangerously-skip-permissions?

codex --dangerously-bypass-approvals-and-sandbox, which OpenAI's docs also give as --yolo. Its help text says “EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed”. Inside a container you trust as the wall, OpenAI suggests --sandbox danger-full-access. To keep Codex's own sandbox and skip only the prompts, use --sandbox workspace-write --ask-for-approval never.

Sources

• Forever Security: Hijacking AI agents via the Downloads folder (2026-10-22, checked 2026-11-08)
• Claude Code Docs: Choose a sandbox environment (checked 2026-11-08)
• Claude Code Docs: Permission modes (checked 2026-11-08)
• Claude Code Docs: Sandboxing (checked 2026-11-08)
• Claude Code Docs: Development containers (checked 2026-11-08)
• Claude Code Docs: Authentication (checked 2026-11-08)
• Claude Code Docs: Claude Code on the web (checked 2026-11-08)
• Claude Code Docs: Cloud environments (checked 2026-11-08)
• Claude Code Docs: Security (checked 2026-11-08)
• Claude Code Docs: Run parallel sessions with worktrees (checked 2026-11-08)
• Claude Code Docs: Set up Claude Code (checked 2026-11-08)
• Claude Code changelog (checked 2026-11-08)
• anthropics/claude-code: reference dev container and init-firewall.sh (checked 2026-11-08)
• anthropics/sandbox-runtime README (checked 2026-11-08)
• npm: @anthropic-ai/claude-code and @openai/codex release dates (checked 2026-11-08)
• Claude pricing (checked 2026-11-08)
• Codex Docs: Agent approvals and security (checked 2026-11-08)
• Codex Docs: Authentication (checked 2026-11-08)
• Codex Docs: Codex Cloud and Cloud environments (checked 2026-11-08)
• Codex Docs: Pricing (checked 2026-11-08)
• Docker Docs: Docker Sandboxes, Install, Get started, Claude Code, Security, FAQ, Cloud sandboxes, Cloud credentials, Isolation layers, and Credentials (checked 2026-11-08)
• Docker: Run an agent tutorial (checked 2026-11-08)
• Docker Agentic Platform pricing (checked 2026-11-08)
• exe.dev pricing, architecture, integrations, and egress policy (checked 2026-11-08)
• Fly.io: Sprites, Sprites networking, and pricing (checked 2026-11-08)
• boat.dev pricing and firewall rules (checked 2026-11-08)
• Hetzner Cloud: regular performance servers (checked 2026-11-08)
• E2B pricing and docs (checked 2026-11-08)
• Daytona pricing and isolation docs (checked 2026-11-08)
• GitHub Docs: Managing your personal access tokens (checked 2026-11-08)
• tmux wiki: Getting Started (checked 2026-11-08)
• GitHub issue anthropics/claude-code #10077 (October 21, 2025) and #12637 (November 28, 2025), checked 2026-11-08
• Nx security advisory GHSA-cxm3-wv7p-598c (published August 27, 2025, checked 2026-11-08)
• StepSecurity: s1ngularity, Nx build system package compromised (August 27, 2025, checked 2026-11-08)