Drop brings rootless Linux sandboxing to coding agents run with skipped permissions

A new tool called Drop reached the front page of Hacker News on 22 September through a Show HN post. It is a rootless sandbox for Linux aimed at two increasingly common problems: coding agents running with their permission checks switched off, and software installed from package registries that later turns out to be malicious.

Built for agents that skip permission prompts

A common way to run coding agents is with their permission prompts disabled — the Show HN post references a flag along the lines of --dangerously-skip-permissions — which is convenient, but it means a single hallucinated or injected command can act with the user's full privileges. Drop's website pitches the tool for exactly this situation: the agent runs with its permission-skipping flag, and Drop enforces restrictions at the operating-system level instead.

The site lists the failure modes this covers. A destructive command aimed at the home directory lands on a throwaway home, not the real one. A prompt injection hunting for SSH keys finds nothing to steal. Connections to services listening on localhost are refused.

Rootless by construction

Drop needs no root privileges. According to the announcement, it places each sandboxed program inside a Linux user namespace that carries its own process, mount, network, IPC and cgroup namespaces. Before handing control to the program, Drop strips out all of the capabilities available inside that user namespace, closing off privileged operations such as bind mounts that would otherwise remain possible there.

An optional gVisor layer

Namespaces alone still leave the host kernel in the path of every system call an untrusted program makes. To reduce that exposure, Drop can run programs under gVisor, a user-space kernel. With this option enabled, sandboxed programs no longer touch the host kernel directly, which the project says significantly cuts the chances of a kernel vulnerability being exploited from inside the sandbox.

Containers without the containers

What separates Drop from Docker or Podman, according to its site, is that it reuses the Linux installation you already have. There is no image to build and no container setup to perform; programs already installed on the machine remain available inside the sandbox. The workflow is borrowed from Python's virtualenv: environments are cheap and disposable, and each one gets its own home directory while the user's real home stays hidden from view.

Containment for supply-chain risk

The second advertised use case is package installation. Drop lets you install software from PyPI, npm or any other source without handing it the keys to your user account. If a dependency is malicious, or becomes compromised in a supply-chain attack, the damage stays within the sandbox.

Configuration

What a sandbox can see is defined in a TOML config that names the files, directories and local network services to expose. By default every Drop environment shares a base configuration, so the policy can be written once and new environments spun up without further setup work.

Why it matters

Coding agents with broad shell access have become a mainstream workflow, and the standard advice — do not skip permission prompts — trades convenience against safety in a way many users clearly decline. Drop takes the opposite assumption: the agent will eventually misbehave, whether through hallucination or prompt injection, and the operating system should be the layer enforcing the boundary. Doing this without root privileges and without a container toolchain removes much of the friction that keeps people from sandboxing at all, and the optional gVisor layer trims the sharpest remaining edge, kernel exploitation by untrusted code. The individual pieces are not new — namespaces and gVisor both predate it — but packaging them into a virtualenv-style workflow aimed squarely at coding agents is a direct response to how those agents are actually being run.