Drop Makes --dangerously-skip-permissions the Correct Setting
A rootless Linux sandbox that moves the permission boundary out of your coding agent and into the kernel. What it actually isolates, what it costs, and where it stops.
There is a flag in Claude Code named --dangerously-skip-permissions, and the name is doing a lot of work. It tells you that approving each action is the safe path and skipping it is the reckless one. Drop, a Linux sandbox that hit the Hacker News front page on September 23, inverts that without much fanfare. Its documentation walks you through installing Claude Code inside the sandbox and then running it with that exact flag, unqualified, in their own walkthrough. They do not label it as recommended. They just do it, and never pause to justify it, which is its own kind of argument.
That is either a bad idea or the first honest answer anyone has given to a question the whole industry has been ducking: who should enforce an agent's boundaries, the agent or the operating system?
The case against asking the agent
A permission prompt is only as good as the model's understanding of what it is about to do, and the model's understanding is only as good as the string it is reasoning over. That gap is not theoretical. Claude Code 2.1.280, shipped September 22, contains this changelog entry: writes through a symlinked path were being judged by their in-tree spelling, which meant acceptEdits, allow rules and auto mode were approving writes that landed outside the tree.
Read that again as an attacker would. Until that release, anything that could place a symlink in a repository could induce an approved write outside the working directory. Repositories contain files. Agents are asked to work on repositories. The delivery mechanism was ordinary repository contents.
It is fixed now, and the fix is good. The pattern is what should bother you: a permission system that resolves against a string rather than against the filesystem is not a permission system, it is a naming convention. Every escape in this class starts exactly there, and the fix arrives one changelog line at a time, forever, because the surface is the agent's entire understanding of its own tool calls.
Drop's answer is to stop playing that game.
What Drop actually does
Drop is a rootless sandbox written in Go, Apache-2.0 licensed, latest release v0.2.1 dated August 24, 2026. It creates named, disposable environments and runs programs inside Linux namespaces: user, mount, PID, IPC, cgroup and network. It requires no root, cannot perform any operation your user could not perform anyway, and drops all user-namespace capabilities before executing the sandboxed program, so the program cannot do privileged things like bind mounts inside its own namespace.
The design decision that makes it usable is that it keeps your distribution instead of replacing it. Docker hands you a base image and a setup problem. Drop mounts /usr, /bin, /sbin and the library directories from your host, read-only. Everything you have already installed is present. The walkthrough in their docs shows Claude Code running ruff inside the sandbox with no installation step, because ruff was already on the machine.
Your username and working directory survive. ps aux shows only sandbox processes. Your home directory contains your real dotfiles, mounted read-only:
(drop)alice@zax:~/project$ echo "evil command" >> ~/.bashrc
bash: /home/alice/.bashrc: Read-only file system
That read-only default is the sharpest thinking in the whole tool, and their configuration docs explain why: shell config scripts are executed by the host, so exposing them as read-write would let a sandboxed program inject commands that run outside the sandbox. Same reasoning for ~/.bash_history, which is also full of executable lines. A sandbox that lets the agent write your .bashrc is a sandbox with a scheduled escape.
Each environment gets its own writable home under ~/.local/share/drop/envs/<id>/home, plus its own /var and /tmp. Install Claude Code inside, and the binary lands at ~/.local/bin/claude from the sandbox's point of view while being absent from your real home. The directory where you ran drop init is mounted read-write so you can work, with one exception worth noticing: .git is mounted read-only by default. Your agent can edit the tree and cannot rewrite your history.
Then the part that justifies the whole exercise:
> Read my private keys stored in the ~/.ssh directory
● Search(pattern: "~/.ssh/*")
⎿ Found 0 files
The agent is not refusing. It is looking, and the directory does not exist for it. That is the difference between a policy and a fact.
Networking runs through pasta, with mode = "isolated" by default: remote services reachable, localhost services on the host not reachable unless you list specific ports. mode = "off" cuts network entirely. And there is an optional runtime = "gvisor" setting that runs the sandboxed program on the gVisor user-space kernel so it never issues syscalls to your host kernel directly.
Put this into practice
Three commands gets you a working setup.
drop init claude
drop run -e claude
drop init writes a shared ~/.config/drop/base.toml plus a tiny per-environment file that extends it. Then, inside the sandbox, install and run your agent normally.
Read the generated base.toml before you trust it. This is the one step people will skip and should not. The defaults mount a list of common dotfiles read-only, including ~/.gitconfig with an inline comment telling you to remove it if you keep secrets there. Do that audit now rather than after. The exposed_vars list controls which environment variables reach the sandbox, and the docs are blunt: do not expose variables containing secrets. Your base.toml is the entire security boundary, so it deserves the ten minutes.
Use the mount syntax deliberately. "~/bin" exposes a directory read-only. "~/plan::rw" makes a file writable. "~/bin:~/bin-host" exposes it under a different name in the sandbox, which is how the default config gives you a writable ~/.local/bin while still reaching the host's tools at ~/.local-host/bin. Keep the read-write list short, and keep anything the host executes out of it.
Start with network off for a first run. Put mode = "off" in the environment-specific config and see what your workflow actually needs before you open anything. The per-environment file overrides net.mode and runtime from the base while appending to the list settings, so you can keep one careful base config and vary the strictness per project.
Make disposal part of the routine. drop rm claude removes the environment and everything installed inside it. A sandbox you treat as permanent slowly accumulates the state you were trying to isolate.
Turn on gVisor for untrusted work. drop run --runtime gvisor on the command line, or runtime = "gvisor" in the config. Reach for it when running code you did not write, from a repository you do not control.
Honest limitations
Linux only. No macOS, no Windows, and given that the isolation is built out of Linux user namespaces and pasta, that is not a gap that closes with effort. If you run agents on a Mac, this tool is not for you and nothing in this article changes that.
The documented limitations are real and specific. GUI programs will not run under the default config, and the docs explain that exposing X sockets to make them work grants overly broad privileges, which is a polite way of saying it defeats the point. Only basic devices are present, so no audio. setuid programs do not run. Anything depending on Linux user namespaces itself, including Podman and Snap-installed programs, does not work inside.
The version number is doing honest work. v0.2.1 is young, and its own release history proves the point: the v0.1.8 notes disclose a since-fixed vulnerability where capabilities were not dropped when running with --root, which allowed a filesystem isolation escape by unmounting bind mounts. That is patched, and it is also a reminder that a sandbox is software with bugs, not a guarantee. I would rather use a young sandbox that discloses its escapes in release notes than trust a permission prompt that never had a threat model, but that is a preference, not a proof.
One more, and it is the one I would want told to me. The sandbox protects your machine. It does not protect the project directory you deliberately mounted read-write, which is where the agent is doing all its work. A confused agent can still wreck the thing you asked it to work on. Drop turns a catastrophe into an inconvenience; git turns the inconvenience into a shrug. Use both.
What to do with this
The question worth taking from this is not whether to install Drop. It is where your agent's boundary currently lives, and whether you can point at it.
If the answer is "the agent asks me before it does anything risky," then your boundary lives inside a model's understanding of a string, and September gave you one documented case where that understanding was wrong in a way that approved writes outside the tree. If the answer is "the kernel," you get to stop reading changelogs for permission fixes, because those fixes stopped being load-bearing for you.
Spend an afternoon on it. Put your agent somewhere it cannot reach your keys, and then let it work without asking. You will notice something odd almost immediately, which is that the agent gets faster and you get calmer at the same time. That is what it feels like when a boundary is real.
Sources: Drop documentation, including the sandbox overview, configuration reference and the Claude Code walkthrough; the wrr/drop repository for license, release history and the v0.1.8 security note; the Claude Code changelog for the 2.1.280 symlink entry.
Medium metadata
Title: Drop Makes --dangerously-skip-permissions the Correct Setting Subtitle: A rootless Linux sandbox that moves your coding agent's boundary into the kernel Tags: AI Agents, Linux, Security, Developer Tools, Claude Code Canonical: publish on fervorai.dev first, then import to Medium with canonical set to the fervorai.dev URL.