claude --dangerously-skip-permissions: every safe way to run it in 2026

The permission asks are the slowest part of Claude Code. That's why the first thing I was looking for was --dangerously-skip-permissions, it was a breaking moment for me but also a new risk. My first thought was what if it does read my private keys from ~/.ssh? What if it accesses my other projects or sensitive resources shared by my clients? One wrong action and it can remove not relevant files. What's even worse for me - it will install python libs used for the dev session and flood my Mac with that, it's terrible for people like me who love to keep the workstation clean! I'm letting Claude Code to work for hours or even night without me around, the permissions prompt issue was solved by the flag but how not to risk my Mac and confidential files? After reading Anthropics docs I have found it's pointing to the containers direction, VMs or sandboxes. Ok but which one? What are the differences? That's the overview for September 2026 as I'm writing this. The mental model, rate each answer with a short question: what are the boundaries of the agent inside? Two biggest problems I've noticed are making the biggest damage. Leak of our sensitive/confidential data and the unrecoverable removal. Breaking the kernel isolation is real but rare and almost never happens during a day-to-day work, it has to be intentional. Keys leaks are normal these days and happens all the time. So what really matters is the boundary between your agent and your data, not between your agent and the virtualization kernel. Option 1: built in /sandbox Claude Code has its own system level sandbox (seatbelt on macOS, bubblewrap on Linux). It's free, it's there and it's worth keeping it enabled. The catch, read the fine print how does it work when working without the permission prompts: only bash commands are included (files tools, MCP servers and hooks work outside of it), your hard drive is available for read (except a few default-denied dirs) unless you block it or mask the paths, one by one. There is also a gate so it retries failed commands outside the sandbox. Anthropic says: it's not enough to run the agent unsupervised. Great pick if you plan to sit staring at the terminal. It's not solving my case, running the Claude Code with the bypass permissions flag. Option 2: sandbox runtime (beta) @anthropic-ai/sandbox-runtime wraps the Claude Code with the same system mechanism without containerisation. That's the most interesting thing Anthropic released in that area. It's still in beta, research preview which you have to assemble yourself bit by bit. The same model, tell us what you want to protect, your hard drive is in a read mode without the paths you point in your configuration. In order to protect your key you have to remember about it, if you add a new one there you have to remember about it :) on Linux the rules are computed on start so a fresh git clone during the session lands outside of it. Worth watching, I won't run the night session on it, not yet. Option 3: dev container Real boundary around the whole session. Anthropic has published a complete configuration with a firewall by default rejecting everything, made directly for the skip permissions flag. Cost: you have to use a devcontainer compatible editor (VS Code, JetBrains, Cursor, Codespaces) or the CLI. You have to edit a JSON and a Dockerfile and rebuild the image to apply the changes. You have to handle and make yourself the support for clipboard, session persistence and switching between project. If this is your way, defining the toolchain as an image and VS Code is your home, this might be something for you. Option 4: Docker Sandboxes (micro VMs) Dockers own product to run the agent in microVM: custom kernel, custom daemon, the strongest local isolation from the list. If you are going to work with untrusted codebase or kernel exploits - take it and don't read further. The costs are relevant to the solution, its heaviest from all the options, it has its own stack and does run on macOS (Sonoma 14+, Apple Silicon), Windows 11 and Linux (Ubuntu 24.04+, needs KVM). For your own agent and your own repositories its over-engineered, you don't need such a strong boundaries for the real incidents that actually happens. Option 5: you run your own docker container Mount single project to the container, put the code inside, install the Claude Code and start it with the bypass protection flag. There are good articles how to do that with real examples. A good and clean writeup is a claude-pod. Building it you can really deep dive and understand how does it work, it really does. Then while using it you are finding the gaps. You cannot paste a screen into the terminal. Files are root owned. Sessions are destroyed when docker is restarted. The tool you install disappears with the container. Every fix takes time, needs multiple iterations and you're starting to be frustrated by this used to be perfect solution. And now you have to maintain that! This is what I'm using now I have built the Cleat. I wanted the Option 5 without weekends spent on covering the gaps and maintaining the containers. It's a single bash file on MIT license. Type cleat in your project and you land in Claude Code with the bypassed prompts flag enabled, inside a Docker container associated with a single project. The security model is a construction, not a configuration. Your SSH keys, cloud files and dotfiles are not blocked by a rule you wrote. These are just not available in the container! There is no list to maintain and there is nothing to remember. When a project needs your identity, a git access or ssh key you can opt-in these with per project capabilities, only one single container receives that. The rest is a boring stuff which makes your cleat container work the same way as vanilla Claude Code: working clipboard, ctrl+v shortcut to paste image or screenshot from your host into the containers Claude, files belongs to you on the file system ownership level, stop and resume with a full context, [setup] section to make your tools to survive, works with every engine you already have (Docker Desktop, OrbStack, Colima, rootless Linux and more). brew install cleatdev/tap/cleat cd your-project && cleat Honest scope A comparison which hides the weak points is an advertisement: it's a container, not a microVM so it's not protecting you against kernel exploits. For now the box has a full egress to the network. The project you mount is fully available inside so secrets stored inside are still accessible and vulnerable. The boundary is between the agent and everything you have. Choose by situation | Use case | Option | |---|---| | Quick session with supervision | built-in /sandbox with auto mode enabled | | Unsupervised work on your own repositories | Cleat | | Team with a toolchain as an image in VS Code | dev container | | Untrusted code base, kernel risk | Docker Sandboxes or VM | | No Docker available on the machine | today /sandbox, sandbox runtime once it becomes mature | I'm holding a complete version of this comparison, with the sources and the weaknesses of every option (mine too) under cleat.sh/compare. If you find some falsy or outdated parts or statements please report that on the GitHub and I will address that as fast as possible. Top comments (0)