wrr

drop

Go2026–2026

wrr / drop

drop

Linux sandboxing that doesn't get in your way

AI & Machine Learning Systems & Infrastructure Security & Privacy

Explore on GitHub Read Hacker News discussions

2Distinct people

10Mentions

0Explicit recommenders

403GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Linux sandboxing that doesn't get in your way

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by week10 dated mentions

Observed mentions: 2026-03-24 12:27:35 UTC to 2026-08-11 16:07:54 UTC. Weeks start Monday, UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
Mar 23	2026-03-23 00:00:00 UTC	2026-03-30 00:00:00 UTC	2	1	1
Mar 30	2026-03-30 00:00:00 UTC	2026-04-06 00:00:00 UTC	2	1	1
Apr 6	2026-04-06 00:00:00 UTC	2026-04-13 00:00:00 UTC	0	0	0
Apr 13	2026-04-13 00:00:00 UTC	2026-04-20 00:00:00 UTC	1	0	1
Apr 20	2026-04-20 00:00:00 UTC	2026-04-27 00:00:00 UTC	0	0	0
Apr 27	2026-04-27 00:00:00 UTC	2026-05-04 00:00:00 UTC	0	0	0
May 4	2026-05-04 00:00:00 UTC	2026-05-11 00:00:00 UTC	0	0	0
May 11	2026-05-11 00:00:00 UTC	2026-05-18 00:00:00 UTC	0	0	0
May 18	2026-05-18 00:00:00 UTC	2026-05-25 00:00:00 UTC	0	0	0
May 25	2026-05-25 00:00:00 UTC	2026-06-01 00:00:00 UTC	0	0	0
Jun 1	2026-06-01 00:00:00 UTC	2026-06-08 00:00:00 UTC	0	0	0
Jun 8	2026-06-08 00:00:00 UTC	2026-06-15 00:00:00 UTC	1	0	1
Jun 15	2026-06-15 00:00:00 UTC	2026-06-22 00:00:00 UTC	0	0	0
Jun 22	2026-06-22 00:00:00 UTC	2026-06-29 00:00:00 UTC	1	0	1
Jun 29	2026-06-29 00:00:00 UTC	2026-07-06 00:00:00 UTC	0	0	0
Jul 6	2026-07-06 00:00:00 UTC	2026-07-13 00:00:00 UTC	0	0	0
Jul 13	2026-07-13 00:00:00 UTC	2026-07-20 00:00:00 UTC	2	0	2
Jul 20	2026-07-20 00:00:00 UTC	2026-07-27 00:00:00 UTC	0	0	0
Jul 27	2026-07-27 00:00:00 UTC	2026-08-03 00:00:00 UTC	0	0	0
Aug 3	2026-08-03 00:00:00 UTC	2026-08-10 00:00:00 UTC	0	0	0
Aug 10	2026-08-10 00:00:00 UTC	2026-08-17 00:00:00 UTC	1	0	1

What Hacker News says

10 sources

neop1x·Aug 11, 2026

On Linux I am using https://github.com/wrr/drop which configures bubblewrap based on a simple yaml config specific for the project path and it is enough for me. I won't use anything requiring a login.

In Docker Sandboxes – Disposable, isolated sandboxes for AI agents

neop1x·Jul 15, 2026

It's easy but very inconvenient. Drop sandbox [1] or Docker are much more convenient alternatives to user/group isolation for this purpose. [1] https://github.com/wrr/drop

In I tricked Claude into leaking your deepest, darkest secrets

mixedbit·Jul 13, 2026

I work on a sandbox which has similar isolation level to Podman (rootless Linux user namespaces), but with UX optimized for local development work. Take a look: https://github.com/wrr/drop Basically, you don't enter a separate container in which you install a new distro, but you run on top of your current distro. You have environment specific home dirs which isolate your original home, but can have some files, such as configs, mounted from your original home (mostly in read-only mode).

In Grok CLI uploaded the whole home directory to GCS

mixedbit·Jun 28, 2026

I work on a Linux sandbox that makes it easy to hide sensitive files from AI agents while keeping the files they need accessible. Check it out: https://github.com/wrr/drop

In A way to exclude sensitive files issue still open for OpenAI Codex

mixedbit·Jun 8, 2026

I made a sandbox to productively work with agents while restricting files they can read and write: https://github.com/wrr/drop

In Ask HN: What are tools you have made for yourself since the advent of AI?

mixedbit·Apr 13, 2026

I'm working on a sandbox for Linux terminal work with UX similar to Python virtualenv: https://github.com/wrr/drop

In Ask HN: What Are You Working On? (April 2026)

mixedbit·Mar 31, 2026

Check also https://github.com/wrr/drop which is a higher-level tool than bwrap. It allows you to make such isolated sandboxes with minimal configuration.

In Axios compromised on NPM – Malicious versions drop remote access trojan

mixedbit·Mar 30, 2026Submission

Show HN: Sandbox agents without losing your dev environment

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

Read the rest

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.

4 points · Open discussion

mixedbit·Mar 28, 2026

I work on a sandboxing tool similarly based on an idea to point the user home dir to a separate location (https://github.com/wrr/drop). While I experimented with using overlayfs to isolate changes to the filesystem and it worked well as a proof-of-concept, overlayfs specification is quite restrictive regarding how it can be mounted to prevent undefined behaviors. I wonder if and how jai managed to address these limitations of overlayfs. Basically, the same dir should not be mounted as an overlayfs upper layer by different overlayfs mounts. If you run 'jai bash' twice in different terminals, do the two instances get two different writable home dir overlays, or the same one? In the second case, is the second 'jai bash' command joining the mount namespace of the first one, or create a new one with the same shared upper dir? This limitation o

Read the rest

f overlays is described here: https://docs.kernel.org/filesystems/overlayfs.html : 'Using an upper layer path and/or a workdir path that are already used by another overlay mount is not allowed and may fail with EBUSY. Using partially overlapping paths is not allowed and may fail with EBUSY. If files are accessed from two overlayfs mounts which share or overlap the upper layer and/or workdir path, the behavior of the overlay is undefined, though it will not result in a crash or deadlock.'

In Go hard on agents, not on your filesystem

mixedbit·Mar 24, 2026Submission

Show HN: Drop – Linux sandboxing for LLM agents and untrusted code

Drop is a Linux sandboxing tool with a focus on a productive local workflow. Drop allows you to easily create sandboxed environments that isolate executed programs while preserving as many aspects of your work environment as possible. Drop uses your existing distribution - your installed programs, your username, filesystem paths, config files carry over into the sandbox. 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 hug

Read the rest

e 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.

1 points · Open discussion