
Drop: a rootless Linux sandbox for programs and coding agents
Drop is an open-source Linux sandbox that isolates programs and coding agents in disposable environments. It needs no root, reuses the distribution already installed instead of containers, and can run code on gVisor's user-space kernel.
Drop is an open-source Linux sandbox that isolates individual programs and coding agents in disposable environments without adopting containers. Published at droprun.sh with its source on GitHub, it appeared on Hacker News as a Show HN submission and tackles the same problem as Docker or Podman in a lighter way.
Rootless isolation
The workflow is inspired by Python's virtualenv: you create an environment, enter it and work as usual, while the isolation is enforced by the operating system. Drop does not require root. Each environment runs in a Linux user namespace with its own process, mount, network, IPC and cgroup namespaces, and before a sandboxed program starts, Drop drops all user-namespace capabilities, so it cannot perform privileged operations such as bind mounts.
Every environment gets its own persistent home directory while the original home is hidden. System directories are mounted from the host read-only, /var and /tmp are private, only a few basic devices are available, and connections to services listening on localhost are denied by default; networking is handled by pasta.
What it is for
The main use case is coding agents. Running an agent without permission prompts is less risky when the operating system, not the model, enforces the boundaries: a hallucinated rm -rf ~ cannot touch the real home directory, and a prompt injection aimed at ~/.ssh finds nothing. The second use case is third-party software — packages from PyPI or npm run inside an environment, so a malicious or compromised release stays contained.
Unlike container runtimes, Drop uses the distribution already installed on the machine: no image to build, no container setup, and the host's programs available as they are. A TOML file decides which files, directories and local services are exposed, and all environments share a base config by default.
gVisor and setup
Two runtimes are available: the default native runtime runs programs directly on the host kernel, while gvisor additionally runs them on gVisor's user-space kernel, so syscalls do not reach the host kernel directly. It requires runsc and is selected in the TOML file (runtime = "gvisor") or per command. gVisor adds syscall overhead and is not fully compatible with the vanilla kernel. Installation needs the passt/pasta package for isolated networking; on Ubuntu 24 an AppArmor profile must allow the drop binary to use user namespaces, and Fedora's SELinux policy has to be extended so pasta can open namespace files.
Limitations
Drop is a terminal tool: GUI programs do not run with the default configuration, exposing X sockets would grant overly broad privileges, and sound playback or recording is impossible. setuid programs do not run at all, and software that itself depends on user namespaces, such as Podman or applications installed through Snap, is not supported.
SiTech — AI-powered web development
We build fast, modern websites and bring AI into real business workflows. Have a project or a question? We'd love to help.