The workflow is inspired by Python's virtualenv: create an environment, enter it, work normally - but with enforced sandboxing. To create a new Drop environment and run a sandboxed shell you simply:

alice@zax:~/project$ drop init && drop run bash

(drop) alice@zax:~/project$ # you are in the sandbox, but your tools and configs are still here.

The need for a tool like Drop had been with me for a long time. I felt uneasy installing and running out-of-distro programs with huge dependency trees and no isolation. On the other hand I dreaded the naked root@b0fecb:/# Docker shell. The main thing that makes Docker great for deploying software - a reproducible, minimal environment - gets in the way of productive development work: tools are missing from a container; config files and environment variables are all unavailable.

The last straw that made me start building Drop was LLM agents. To work well - compile code, run tests, analyze git logs - agents need access to tools installed on the machine. But giving agents unrestricted access is so clearly risky, that almost every HN discussion on agentic workflows includes a rant about a lack of sandboxing.

Drop uses Linux user namespaces (no root required) as the main isolation mechanism, with passt/pasta used for isolated networking.

I'd love to hear what you think.