Drop is a Linux sandboxing tool with a focus on a productive local workflow. It isolates programs and agents while preserving as many aspects of your work environment as possible.
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 environment created with config at /home/alice/.config/drop/home-alice-project.toml
alice@zax:~/project$ drop run
(drop) alice@zax:~/project$ cat ~/.ssh/id_rsa
cat: /home/alice/.ssh/id_rsa: No such file or directory
Each Drop environments gets its own, isolated and easily disposable home dir. To ensure the sandbox matches your actual work environment, selected files and dirs from your original home dir are mounted in the sandbox, most of them read-only.
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 discussion on agentic workflows includes a rant about a lack of sandboxing.
Thanks, I'd love to hear what you think.
0 comments
—
Show HN: Sandbox agents without losing your dev environment · HackerTrans
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:
Each Drop environments gets its own, isolated and easily disposable home dir. To ensure the sandbox matches your actual work environment, selected files and dirs from your original home dir are mounted in the sandbox, most of them read-only.
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 discussion on agentic workflows includes a rant about a lack of sandboxing.
Thanks, I'd love to hear what you think.