8 ms·

Agent Safehouse – macOS-native sandboxing for local agents

823 points by atombender 8mo ago

aplomb1026 8mo ago
[flagged]
garganzol 8mo ago
While we have `sandbox-exec` in macOS, we still don't have a proper Docker for macOS. Instead, the current Docker runs on macOS as a Linux VM which is useful but only as a Linux machine goes. Having real macOS Docker would solve the problem this project solves, and 1001 other problems.
- dpe82 8mo ago
  Nitpick, which probably doesn't matter too much in this context but is always good to remember: Docker containers are not security boundaries.
  - PlasmaPower 8mo ago
    Why not? They're definitely not perfect security boundaries, but neither are VMs. I think containers provide a reasonable security/usability tradeoff for a lot of use cases including agents. The primary concern is kernel vulnerabilities, but if you're keeping your kernel up-to-date it's still imo a good security layer. I definitely wouldn't intentionally run malware in it, but it requires an exploit in software with a lot of eyes on it to break out of.
    - dpe82 8mo ago
      It's certainly better than nothing. Hence "probably doesn't matter too much in this context" - but of course it always matters what your threat model is. Your own agents under your control with aligned models and not interacting with attacker data? Should be fine. But too many people just automatically equate docker with strong secure isolation and... well, it can be, sometimes, depending a hundred other variables. Thus the reminder; to foster conversations like this.
  - fredoliveira 8mo ago
    counter-intuitively, the fact that docker on the mac requires a linux-based VM makes it safer than it otherwise would be. But your point stands in general, of course.
- mkagenius 8mo ago
  Apple containers were released a few months back. Been using it to sandbox claude/gemini-cli generated code[1]. You can use it to completely sandbox claude code too. 1. Coderunner - https://github.com/instavm/coderunner https://github.com/instavm/coderunner
  - arianvanp 8mo ago
    That is also Linux VM on MacOS. They're not MacOS containers.. So it's completely pointless / useless for MacOS or iOS development
    - mkagenius 8mo ago
      Oh, yes. I thought GP was mostly worried about shared VM problem.
- PufPufPuf 8mo ago
  What would native containers bring over Linux ones? The performance of VZ emulation is good, existing tools have great UX, and using a virtualized kernel is a bit safer anyways. I regularly use a Lima VM as a VSCode remote workspace to run yolo agents in.
  - hirvi74 8mo ago
    VZ has been exceptional for me. I have been running headless VMs with Lima and VZ for a while now with absolutely zero problems. I just mount a directory I want Claude Code to be able to see and nothing more.
  - garganzol 8mo ago
    Sometimes you just have to run native software. In my case, that means macOS build agents using Xcode and Apple toolchains which are only available on macOS. It's not a pleasure to run them in a mutable environment where everything has a floating state as I do now. Native Docker for macOS would totally solve that.
  - qalmakka 8mo ago
    > What would native containers bring over Linux ones? What would a Phillips screwdriver bring over a flathead screwdriver? Sometimes you don't want/need the flathead screwdriver, simple as that. There are macOS-specific jobs you need to run in macOS, such as xcode toolchains etc. You can try cross compiling, but it's a pain and ridiculous given that 100% of every other OS supports containers natively (including windows). It's clear to me that Apple is trying to make the ratio jobs/#MacMinis as small as possible
- hrmtst93837 8mo ago
  [flagged]
- egorfine 8mo ago
  > Having real macOS Docker would solve the problem I'm very slowly working on a mock docker implementation for macOS that uses ephemeral VM to launch a true guest macOS and perform commands as per Dockerfile/copies files/etc. I use it internally for builds. No public repo yet though. Not sure if there is demand.
xyzzy_plugh 8mo ago
This is just a wrapper around sandbox-exec. It's nice that there are a ton of presets that have been thought out, since 90% of wielding sandbox-exec is correctly scoping it to whatever the inner environment requires (the other 90% is figuring out how sandbox-exec works). I like that it's just a shell script. I do wish that there was a simple way to sandbox programs with an overlay or copy-on-write semantics (or better yet bind mounts). I don't care if, in the process of doing some work, an LLM agent modifies .bashrc -- I only care if it modifies _my_ .bashrc
- tuananh 8mo ago
  isn't sandbox-exec already deprecated?
  - e1g 8mo ago
    Yes, for about a decade. But it’s available everywhere, and still works - and protects us - like brand new!
    - rvz 8mo ago
      It's quite naive to assume that. There is a reason why it is deprecated by Apple. Apple is likely preparing to remove it for a secure alternative and all it takes is someone to find a single or a bunch of multiple vulnerabilities in sandbox-exec to give a wake up call to everyone why were they using it in the first place. I predict that there is a CVE lurking in sandbox-exec waiting to be discovered.
      - TheTon 8mo ago
        On the other hand, the underlying functionality for sandboxing is used heavily throughout the OS, both for App Sandboxes and for Apple’s own system processes. My guess is sandbox-exec is deprecated more because it never was adequately documented rather than because it’s flawed in some way.
        8mo ago
gozucito 8mo ago
so this works the same as Claude Code /sandbox? The innovation being that it's harness-agnostic?
- arianvanp 8mo ago
  That and that the built in sandbox in Claude Code is bad (read only access to everything by default) and tightly coupled (cant modify it or swap it out).
- e1g 8mo ago
  Roughly, yes, but more reliable (and restrictive), as Claude Code has ways to escape its sandbox. This gives more protection and guards across all CLI agnets (Amp, Pi, etc)
e1g 8mo ago
Creator here - didn't expect this to go public so soon. A few notes: 1. I built this because I like my agents to be local. Not in a container, not in a remote server, but running on my finely-tuned machine. This helps me run all agents on full-auto, in peace. 2. Yes, it's just a policy-generator for sandbox-exec. IMO, that's the best part about the project - no dependencies, no fancy tech, no virtualization. But I did put in many hours to identify the minimum required permissions for agents to continue working with auto-updates, keychain integration, and pasting images, etc. There are notes about my investigations into what each agent needs https://agent-safehouse.dev/docs/agent-investigations/ https://agent-safehouse.dev/docs/agent-investigations/ (AI-generated) 3. You don't even need the rest of the project and use just the Policy Builder to generate a single sandbox-exec policy you can put into your dotfiles https://agent-safehouse.dev/policy-builder.html https://agent-safehouse.dev/policy-builder.html
- asabla 8mo ago
  Oh woah! I've been trying to get microsandbox to play nicely. But this is much closer to what I actually need. I glimpsed through the site and the script. But couldn't really see any obvious gotchas. Any you've found so far which hasn't been documented yet?
  - e1g 8mo ago
    Pure TUI is solid - I’ve been running all my pets inside that cage for several weeks with no issues. Auto-updates work, session renewals work, config updates work etc. But lately I’ve been using agents to test via browsers, and starting headless browsers from the agent is flakey. I’m working on that but it’s hard to find a secure default to run Chrome. In the repo, I have policies for running the Claude desktop app and VSCode inside the same sandbox (so can do yolo mode there too), so there is hope for sandboxing headless Chrome as well.
    - asabla 8mo ago
      Yee I gotcha. Did a migration myself last week from using playwright mcp towards playwright-cli instead. Which has been playing much nicer so far. I guess you would run into the same issues you've already mentioned about running chrome headless in one of these sandboxes. I'll for sure keep an eye out for updates. Kudos to the project!
naomi_kynes 8mo ago
The "full-auto" framing is interesting. What happens when the agent hits something it can't resolve autonomously? Even sandboxed, there's a point where the agent needs to ask a question or get approval. Most setups handle this awkwardly: fire a webhook, write to a log, hope the human is watching. The sandbox keeps the agent contained, but doesn't give it a clean "pause and ask" primitive. The agent either guesses (risky) or silently fails (frustrating). Seems like there are two layers: the security boundary (sandbox-exec, containers, etc.) and the communication boundary (how does a contained agent reach the human?). This project nails the first. The second is still awkward for most setups.
- e1g 8mo ago
  Correct, this is for skipping permissions (safely), but does nothing for skipping questions.
- deleted 8mo ago
  [deleted]
- _jdtm 8mo ago
  [dead]
- niyikiza 8mo ago
  The two-layer framing is right. Sandbox-exec contains local blast radius, and that's important. But if the agent already has a credential in memory, sandboxing the filesystem doesn't help. I've been working on a primitive for scoped authorization at the tool call level: what was this agent allowed to do, for which task, signed by whom. The core is open-sourced: https://github.com/tenuo-ai/tenuo https://github.com/tenuo-ai/tenuo
- jamiemallers 8mo ago
  [dead]
tl2do 8mo ago
Intriguing, but... Around last summer (July–August 2025), I desperately needed a sandbox like this. I had multiple disasters with Claude Code and other early AI models. The worst was when Claude Code did a hard git revert to restore a single file, which wiped out ~1000 lines of development work across multiple files. But now, as of March 2026, at least in my experience, agents have become more reliable. With proper guardrails in claude.md and built-in safety measures, I haven't had a major incident in about 3 months. That said, layering multiple safeguards is always recommended—your software assets are your assets. I'd still recommend using something like this. But things are changing, bit by bit.
- jeremyjh 8mo ago
  Prompt injection attacks are very much a thing. It doesn't matter how good the agent is, its vulnerable, and you don't know what you don't know.
  - ramoz 8mo ago
    Where are we at with SOTA or reliable prompt injection detection mechanisms?
- e1g 8mo ago
  No doubt they are getting better, but even a 0.1% chance of “rm -rf” makes it a question of “when” not “if”. And we sure spin that roulette a lot these days. Safehouse makes that 0%, which is categorically different. Also, I don’t want it to be even theoretically possible for some file in node_modules to inject instructions to send my dotfiles to China.
- bilalq 8mo ago
  Look into git reflog. If the changes were committed, it was almost certainly possible to still restore them, even if the commit is no longer in your branch.
  - ZYbCRq22HbJ2y7 8mo ago
    There are probably other tools like this that keep version history based on filesystem events, independent from the project's git repository https://www.jetbrains.com/help/idea/local-history.html https://www.jetbrains.com/help/idea/local-history.html
synparb 8mo ago
I’ve been playing around with https://nono.sh/ https://nono.sh/ , which adds a proxy to the sandbox piece to keep credentials out of the agent’s scope. It’s a little worrisome that everyone is playing catch up on this front and many of the builtin solutions aren’t good.
vivid242 8mo ago
Nice! I‘d be interesting in the things that went wrong during development. Which loopholes were discovered last, if any?
moehj 8mo ago
[dead]
mkagenius 8mo ago
A way to run claude code inside a apple container - $ container system start $ container run -d --name myubuntu ubuntu:latest sleep infinity $ container exec myubuntu bash -c "apt-get update -qq && apt-get install -y openssh-server" $ container exec myubuntu bash -c " apt-get install -y curl && curl -fsSL https://deb.nodesource.com/setup_lts.x | bash - && apt-get install -y nodejs " $ container exec myubuntu npm install -g @anthropic-ai/claude-code $ container exec myubuntu claude --version
- emmelaich 8mo ago
  Thanks, hadn't heard of this! In homebrew, too. https://github.com/apple/container https://github.com/apple/container
- sunnybeetroot 8mo ago
  Lume is also a nice wrapper around it
- terhechte 8mo ago
  Shuru should do exactly what you want: https://shuru.run https://shuru.run
dbmikus 8mo ago
I like that it's all bash. How does this compare with Codex's and Claude's built-in sandboxing?
- e1g 8mo ago
  Claude: can escape its sandbox (there are GitHub issues about this) and, when sandboxed, still has full read access to everything on your machine (SSH keys, API keys, files, etc.) Codex: IIRC, only shell commands are sandboxed; the actual agent runtime is not.
  - dbmikus 8mo ago
    Cool, thanks for explaining!
pash 8mo ago
Sandvault [0] (whose author is around here somewhere), is another approach that combines sandbox-exe with the grand daddy of system sandboxes, the Unix user system. Basically, give an agent its own unprivileged user account (interacting with it via sudo, SSH, and shared directories), then add sandbox-exe on top for finer-grained control of access to system resources. 0. https://github.com/webcoyote/sandvault https://github.com/webcoyote/sandvault
- mikemcquaid 8mo ago
  Yeh I came here to post this. I preferred this approach as user permissions are a bit easier to consistently verify as a second layer of defence. I also found the author to be helpful and responsive and the tool to be nicely minimalistic rather than the usual vibe coded ever expanding mess. ‘brew install sandvault’ and running ‘sv’ should get you going. (full disclosure: I created the Homebrew formula and submitted a few PRs to the project)
  - TheTaytay 8mo ago
    Means a lot coming from you - thanks for taking the time to post, and for taking the time to make the Homebrew formula. (I am also a fan of the author's (webcoyote's) other work.)
zmmmmm 8mo ago
This is great to see. I honestly think that sandboxing is currently THE major challenge that needs to be solved for the tech to fully realise its potential. Yes the early adopters will YOLO it and run agents natively. It won't fly at all longer term or in regulated or more conservative corporate environments, let alone production systems where critical operations or data are in play. The challenge is that we need a much more sophisticated version of sandboxing than anybody has made before. We can start with network, file system and execute permissions - but we need way more than that. For example, if you really need an agent to use a browser to test your application in a live environment, capture screenshots and debug them - you have to give it all kinds of permissions that go beyond what can be constrained with a traditional sandboxing model. If it has to interact with resources that cost money (say, create cloud resources) then you need an agent aware cloud cost / billing constraint. Somehow all this needs to be pulled together into an actual cohesive approach that people can work with in a practical way.
- silverstream 8mo ago
  File-level sandboxing is table stakes at this point — the harder problem is credentials and network. An agent inside sandbox-exec still has your AWS keys, GitHub token, whatever's in the environment. I've been running a setup where a local daemon issues scoped short-lived JWTs to agent processes instead of passing raw credentials through, so a confused agent can't escalate beyond what you explicitly granted. Works well for API access. But like you said, nothing at the filesystem level stops an agent from spinning up 50 EC2 instances on your account.
  - e1g 8mo ago
    > An agent inside sandbox-exec still has your AWS keys, GitHub token, whatever's in the environment. That's not the case with Agent Safehouse - you can give your agent access to select ~/.dotfiles and env, but by default it gets nothing (outside of CWD)
  - ericlevine 8mo ago
    Completely agree. As soon as I had OpenClaw working, I realized actually giving it access to anything was a complete nonstarter after all of the stories about going off the rails due to context limitations [1]. I've been building a self-hosted open sourced tool to try to address this by using an LLM to police the activity of the agent. Having the inmates run the asylum (by having an LLM police the other LLM) seemed like an odd idea, but I've been surprised how effective it's been. You can check it out here if you're curious: https://github.com/clawvisor/clawvisor https://github.com/clawvisor/clawvisor clawvisor.com [1] https://www.tomshardware.com/tech-industry/artificial-intelligence/openclaw-wipes-inbox-of-meta-ai-alignment-director-executive-finds-out-the-hard-way-how-spectacularly-efficient-ai-tool-is-at-maintaining-her-inbox https://www.tomshardware.com/tech-industry/artificial-intell...
nemo44x 8mo ago
Supervisor agent frameworks are going to be a big industry soon. You simply can’t have agents executing commands without a trusted supervisory layer examining and certifying actions. All the issues we get from AI today (hallucinations, goal shift, context decay, etc) get amplified unbelievably fast once you begin scaling agents out due to cascading. The risk being you go to bed and when you wake up your entire infrastructure is gone lol.
gnanagurusrgs 8mo ago
This is the right problem to solve. At Arcade, we see the same gap — agents get shell access, API keys, and network by default. The permissions model is backwards. sandbox-profiles is a solid primitive for local agents. The missing piece in production is the tool layer — even a sandboxed agent can still make dangerous API calls if the MCP tools it has access to aren't individually authed and scoped. The real stack is: sandbox the runtime (what Agent Safehouse does) + scope the tools (what we do with JIT OAuth at the MCP layer). Neither alone is enough. Nice work shipping this. https://www.arcade.dev/blog/ai-agent-auth-challenges-developers https://www.arcade.dev/blog/ai-agent-auth-challenges-develop...
inoki 8mo ago
I'm also working on a cross-platform solution (sandbox-exec on macOS). What if Apple finally drops this after long deprecation?
- e1g 8mo ago
  Let’s make something so popular and useful that they can’t drop it.
srid 8mo ago
If you are using Nix, there's also https://github.com/srid/sandnix https://github.com/srid/sandnix that works on Linux (landrun) and macOS (sandbox-exec).
cjbarber 8mo ago
See also various sandbox tools I and others (e.g. jpeeler) have collected: https://news.ycombinator.com/item?id=47102258 https://news.ycombinator.com/item?id=47102258
- touristtam 7mo ago
  Priceless thank you
davidcann 8mo ago
I made a native macOS app with a GUI for sandbox-exec, plus a network sandbox with per-domain filtering and secrets detection: https://multitui.com/ https://multitui.com/
ashishb 8mo ago
I built something similar for myself that works on both Linux and Mac OS https://github.com/ashishb/amazing-sandbox https://github.com/ashishb/amazing-sandbox
devonkelley 8mo ago
[flagged]
varenc 8mo ago
fun fact about `sandbox-exec`, the macOS util this relies on: Apple officially deprecated it in macOS Sierra back in 2016! Its manpage has been saying it's deprecated for a decade now, yet we're continuing to find great uses for it. And the 'App Sandbox' replacement doesn't work at all for use cases like this where end users define their own sandbox rules. Hope Apple sees this usage and stops any plans to actually deprecate sandbox-exec. I recall a bunch of macOS internal services also rely on it.
- jasomill 8mo ago
  Aside from named profiles, I'm not sure it wasn't born deprecated. In particular, has the profile language ever been documented by anything other than the examples used by the OS and third parties reverse engineering it?
  - varenc 8mo ago
    Good point. I have no idea when it was introduced. Would be funny if it's been deprecated since its existence.
simonw 8mo ago
The challenge I'm finding with sandboxes like this is evaluating them in comparison to each other. This looks like a competent wrapper around sandbox-exec. I've seen a whole lot of similar wrappers emerging over the past few months. What I really need is help figuring out which ones are trustworthy. I think this needs to take the form of documentation combined with clearly explained and readable automated tests. Most sandboxes - including sandbox-exec itself - are massively under-documented. I am going to trust them I need both detailed documentation and proof that they work as advertised.
- e1g 8mo ago
  Thank you for your work - I have sent many of your links to my people. Your point is totally fair for evaluating security tooling. A few notes - 1. I implemented this in Bash to avoid having an opaque binary in the way. 2. All sandbox-exec profiles are split up into individual files by specific agent/integration, and are easily auditable (https://github.com/eugene1g/agent-safehouse/tree/main/profiles https://github.com/eugene1g/agent-safehouse/tree/main/profil...) 3. There are E2E tests validating sandboxing behavior under real agents 4. You don't even need the Safehouse Bash wrapper, and can use the Policy Builder to generate a static policy file with minimal permissions that you can feed to sandbox-exec directly (https://agent-safehouse.dev/policy-builder https://agent-safehouse.dev/policy-builder). Or feed the repo to your LLMs and have them write your own policy from the many examples. 5. This whole repo should be a StrongDM-style readme to copy&paste to your clanker. I might just do that "refactor", but for now added LLM instructions to create your own sandbox-exec profiles https://agent-safehouse.dev/llm-instructions.txt https://agent-safehouse.dev/llm-instructions.txt
  - big_toast 8mo ago
    I love this implementation. Do you find the SBPL deficient in any ways? Would xcodebuild work in this context? Presumably I'd watch a log (or have an agent) and add permissions until it works?
    - e1g 8mo ago
      SBPL is great for filesystem controls and I haven’t hit roadblocks yet. I wish it offered more controls of outbound network requests (ie filtering by domain), but I understand why not. Yes, Safehouse should work for xcodebuild workloads in the way you described - try to run it, watch for failures, extend the profile, try again. Your agent can do this in a loop by itself - just feed it the repo as there are many integrations that are not enabled by default that will help it.
matifali 8mo ago
I wonder why you believe that running agents locally is the best approach. For most people, having agents operate remotely is more effective because the agent can stay active without your local machine needing to remain powered on and connected to the internet 24/7.
- NegativeLatency 8mo ago
  It’s nice having control and ownership of your software. I’m assuming it’s similar to why people run plex, web servers, file sharing, etc Also personally I’d rather not pay monthly fees for stuff if it can be avoided.
  - mikodin 8mo ago
    Piggybacking on this - I think it well equips us for a future when local models are stronger. I for one am grateful for efforts like these
  - paxys 8mo ago
    These agents are all calling APIs that are well beyond your control. How does it matter whether a thin CLI wrapper is running on your computer or not?
- deevus 8mo ago
  For this specific problem I built pixels: https://github.com/deevus/pixels https://github.com/deevus/pixels It supports running on a TrueNAS SCALE server, or via Incus (local or remote). I'm still working on tightening the security posture, but for many types of AI workflows it will be more than sufficient.
- sunnybeetroot 8mo ago
  It’s nice to debug Apple platform projects immediately
Finbarr 8mo ago
Awesome to see a bash-only method of solving this problem. Also like that it alerts on attempts to read restricted stuff. I built yolobox to solve this using docker/apple containers: https://github.com/finbarr/yolobox https://github.com/finbarr/yolobox
sunir 8mo ago
Is clunker some new slang that's different than clanker? I'm asking for a friend of my friend Roku. p.s. thanks for making this; timely as I am playing whackamole with sandboxing right now.
- e1g 8mo ago
  Testing in prod! Thank you, just fixed that typo.
treexs 8mo ago
wow it's interesting how noticeable sites built with claude maybe with the frotnend-design skill are now
- e1g 8mo ago
  IYKYK, it’s the new Bootstrap! The alternative would be “no site”, which is still somehow worse.
poopiokaka 8mo ago
[dead]
wek 8mo ago
Do you have plans to go cross-platform and offer a solution for Windows?
hsaliak 8mo ago
This is a very nice and clean implementation. Related to this - I've been exploring injecting landlock and seccomp profiles directly into the elf binary, so that applications that are backed by some LLM, but want to 'do the right thing' can lock themselves out. This ships a custom process loader (that reads the .sandbox section) and applies the policies, not unlike bubblewrap which uses namespaces). The loading can be pushed to a kernel module in the future. https://github.com/hsaliak/sacre_bleu https://github.com/hsaliak/sacre_bleu very rough around the edges, but it works. In the past there were apps that either behaved well, or had malicious intent, but with these LLM backed apps, you are going to see apps that want to behave well, but cannot guarantee it. We are going to see a lot of experimentation in this space until the UX settles!
- ClaudioAnthrop 8mo ago
  [dead]
boxedemp 8mo ago
Fantastic! I had been using dockers but this might be better!
cuber_messenger 8mo ago
It's the exact auth control I want. However, it seems it's not a safehouse for local agents, but a safe cage, IMHO. After all, it prevents damage they might cause.
alpb 8mo ago
As I understand it, the problem nowadays doesn't seem to be so much that the agent is going to rm -rf / my host, it's more like it's going to connect to a production system that I'm authorized to on my machine or a database tool, and then it's going to run a potentially destructive command. There is a ton of value of running agents against production systems to troubleshoot things, but there are not enough guardrails to prevent destructive actions from the get-go. The solution seems to be specific to each system, and filesystem is just one aspect out of many.
- crossroadsguy 8mo ago
  As I understand it, the problem is these apps/agents can do all of these and lot more (if not absolutely everything, while I am sure it can go quite close to doing that). Solution could be two parts: OS bringing better and easier to use OS limitations (more granular permissions; install time options and defaults which will be visible to user right there and user can reject that with choices like: - “ask later” - “no” - “fuck no” with eli5 level GUIs (and well documented). Hell, a lot of these are already solved for mobile OS. While not taking away tools away from hands of the user who wants to go inside and open things up (with clear intention and effort; without having to notarise some shit or pay someone). 2. Then apps[1] having to, forced to, adhere to use those or never getting installed. [1] So no treating of agents as some “other” kinds of apps. Just limit it for every app (unless user explicitly decides to open things up). It will also be a great time to nuke the despicable mess like Electron Helpers and shit and app devs considering it completely fine to install a trillion other “things” when user installed just one app without explaining it in the beginning (and hence forced to keep their apps’ tentacles simple and limited)
openclaw01 8mo ago
[dead]
abhisek 8mo ago
I think this is the right approach to building sandbox for agents ie. over existing OS native sandbox capabilities so that they are truly enforced. However the challenge is, sandbox profiles (rules) are always workload specific. How do you define “least privilege” for a workload and then enforce it through the sandbox. Which is why general sandboxes wont be useful or even feasible. The value is observing and probably auto-generating baseline policy for a given workload. Wrong or overly relaxed policies would make sandbox ineffective against real threats it is expected to protect against.
paxys 8mo ago
Not sure I understand this. Agent CLIs already use sandbox-exec, and you can configure granular permissions. You are basically saying - give the agents access to everything, and configure permissions in this second sandbox-exec wrapper on top. But why use this over editing the CLI's settings file directly (e.g. https://code.claude.com/docs/en/sandboxing#configure-sandboxing https://code.claude.com/docs/en/sandboxing#configure-sandbox...)?
- scosman 8mo ago
  I have sandbox-exec setup for Claude like you suggest, but I’m not sure every CLI supports it? Claude only added it a month or two ago. A wrapper CLI that allows any command to be sandboxed is pretty appealing (Claude config was not trivial). The downside is that it requires access to more than it technically needs (Claude keys for example). I’m working on a version where you sandbox the agent’s Bash tool, not the agent itself. https://github.com/Kiln-AI/Kilntainers https://github.com/Kiln-AI/Kilntainers
  - snthpy 8mo ago
    I like the idea but not the MCP part. How about using bash-tool to intercept the commands and then passing them onto the containers? https://github.com/vercel-labs/bash-tool https://github.com/vercel-labs/bash-tool
    - snthpy 8mo ago
      My bad, looks like I misunderstood how bash-tool works. Then how about running Claude Code or your harness of choice inside bubblewrap with a shim/stub for the base binary? https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap
    - scosman 8mo ago
      That's exactly what it does -- the bash commands are passed into the containers. It also manages container lifecycle (starting on first request, cleanup on connection shutdown). If you're using an agent tool that already includes an existing bash tool which calls host OS, just remove that one and add this.
w10-1 8mo ago
But... why not just run macOS in a VM? If/since AI agents work continuously, it seems like running macOS in a VM (via the virtualization framework directly) is the most secure solution and requires a lot less verification than any sandboxing script. (Critical feature: no access to my keychain.) AI agents are not at all like container deploys which come and go with sub-second speed, and need to be small enough that you can run many at a time. (If you're running local inference, that's the primary resource hog.) I'm not too worried about multiple agents in the same vm stepping on each other. I give them different work-trees or directory trees; if they step over 1% of the time, it's not a risk to the bare-metal system. Not sure if I'm missing something...
- sunnybeetroot 8mo ago
  1 limitation is Apple Virtualisation does not offer USB passthrough for connecting to iPhones for iOS development.
- llimllib 8mo ago
  For me, it's file system latency on mac os when virtualizing that kills me. Cargo, npm, pip, etc create many small files and there's a high per-file latency on the FS layer
datapolitical 8mo ago
This really is not going to be safe on something like Mac or Windows until it’s built into the OS. But given how fast agents are moving, I would be shocked if such tools were not already being built
ai_fry_ur_brain 8mo ago
Docker...
Agent_Builder 8mo ago
[dead]
grun 8mo ago
similar project https://github.com/trailofbits/claude-code-devcontainer https://github.com/trailofbits/claude-code-devcontainer
ashniu123 8mo ago
How's this different from https://container-use.com https://container-use.com?
sagarpatil 8mo ago
Looks good. I’ll give it a try.
jeff_antseed 8mo ago
[dead]
- edf13 8mo ago
  We are a different approach and are targeting Linux for our first release (Windows & Mac shortly afterwards). Taking more of an automated supervisor approach with limited manual approval for edge cases. Grith.ai
- carderne 8mo ago
  There is sandbox-runtime [1] from Anthropic that uses bubblewrap to sandbox on Linux (and works the same as OP on macOS). You can look at the code to see how it uses it. Anthropic's tool only support read blacklist, not a whitelist, so I forked it yesterday to support that [2]. [1] https://github.com/anthropic-experimental/sandbox-runtime https://github.com/anthropic-experimental/sandbox-runtime [2] https://github.com/carderne/sandbox-runtime https://github.com/carderne/sandbox-runtime
carderne 8mo ago
How do agents tend to deal with getting blocked? Messing around with sandboxes, I've quite even seen them get blocked, assume something is wrong, and go _crazy_ trying to get around the block, never stopping to ask for user input. It might be good to add to the error message: "This is deliberate, don't try to get around it." For those using pi, I've built something similar[1] that works on macOS+Linux, using sandbox-exec/bubblewrap. Only benefit over OP is that there's some UX for temporarilily/permanently bypassing blocks. [1] https://github.com/carderne/pi-sandbox https://github.com/carderne/pi-sandbox
- e1g 8mo ago
  Claude Code and Codex quickly figure out they are inside sandbox-exec environment. Maybe because they know it internally. Other agents often realize they are being blocked, and I haven't seen them go haywire yet. Big love for Pi - it was the first integration I added to Safehouse. I wanted something that offers strong guarantees across all agents (I test and write them nonstop), has no dependencies (e.g., the Node runtime), and is easy to customize, so I didn't use the Anthropic sandbox-runtime.
  - carderne 8mo ago
    Interesting, that's not been my experience! Maybe you've got the list of things to allow/block just right. While testing different policies I've frequently seen Opus 4.6 go absolutely nuts trying to get past a block, unless I made it more clear what was happening. Yeah I think for general use the transparency of what your thing does is really great compared to a pile of TypeScript and whatnot.
- gbrindisi 8mo ago
  ah I also did my own sandbox and at least twice the agent inside tried really hard to go around the firewall, so I ended up intercepting calls to `connect` to return a message that says "Connection refused by the sandbox, don't try to bypass". Code here: https://github.com/gbrindisi/agentbox https://github.com/gbrindisi/agentbox
SiteMgrAI 8mo ago
Sandboxing is going to be table stakes for any serious deployment of AI agents in regulated industries. In sectors like construction, healthcare, or finance, you cannot have an agent with unrestricted filesystem or network access making decisions that affect safety-critical documentation. The macOS sandbox approach is smart because it leverages the OS-level enforcement rather than relying on application-layer restrictions that an agent could potentially reason its way around. The real question is how you balance useful tool access with meaningful containment when the whole point of agents is autonomous action.
brutuscat 8mo ago
What do you think of sandbox-exec being marked as deprecated? https://news.ycombinator.com/item?id=31973232 https://news.ycombinator.com/item?id=31973232 https://github.com/openai/codex/issues/215 https://github.com/openai/codex/issues/215
yowang 8mo ago
[dead]
octoclaw 8mo ago
[dead]
ptak_dev 8mo ago
[flagged]
- brap 8mo ago
  I think these are 2 independent axis: 1. Destructive by accident 2. Destructive because it was prompt-injected And 1. Fucks up filesystem 2. Fucks up external systems via credentials
- eelke 8mo ago
  Problem 2 is mitigated by only allowing trusted sources through firewall rules.
- tcbrah 8mo ago
  problem 2 is actually scarier than most people realize because it compounds. your agent reads a README in some dependency, that README has injection instructions, now the agent is acting on behalf of the attacker with whatever permissions you gave it. filesystem sandboxing doesnt help because the dangerous action might be "write a backdoor into the file i already have write access to" which is completely within the sandbox rules. the short-lived scoped credentials approach someone mentioned upthread is probably the best practical mitigation right now. but even that breaks down when the agent legitimately needs broad access to do its job - like if its refactoring across a monorepo it kinda needs write access to everything. i think the actual answer long term is something closer to capability-based security where each tool call gets its own token scoped to exactly what that specific action needs. but nobody has built that yet in a way that doesnt make the agent 10x slower.
- wilkystyle 8mo ago
  Matchlock[0] is probably the best solution I've come across so far WRT problem 1 and 2: > Matchlock is a CLI tool for running AI agents in ephemeral microVMs - with network allowlisting, secret injection via MITM proxy, and VM-level isolation. Your secrets never enter the VM. In a nutshell, it solves problem #2 through a combination of a network allowlist and secret masking/injection on a per-host basis. Secrets are never actually exposed inside the sandbox. A placeholder string is used inside the sandbox, and the mitm proxy layer replaces the placeholder string with the actual secret key outside of the sandbox before sending the request along to its original destination. Furthermore, because secrets are available to the sandbox only on a per-host basis, you can specify that you want to share OPENAI_API_KEY only with api.openai.com, and that is the only host for which the placeholder string will be replaced with the actual secret value. edit to actually add the link [0] https://github.com/jingkaihe/matchlock https://github.com/jingkaihe/matchlock
guimbuilds 8mo ago
Interesting, we're tackling a different layer of the same problem, snapshot before every run + one-click rollback instead of kernel sandboxing. Complementary approaches. Nice work.
devrimozcay 8mo ago
Interesting direction. One thing we've been seeing with production AI agents is that the real risk isn't just filesystem access, but the chain of actions agents can take once they have tool access. Even a simple log-reading capability can escalate if the agent starts triggering automated workflows or calling internal APIs. We've been experimenting with incident-aware agents that detect abnormal behavior and automatically generate incident reports with suggested fixes. Curious if you're thinking about integrating behavioral monitoring or anomaly detection on top of the sandbox layer.
rwky 8mo ago
Fore Linux firejail works well https://firejail.wordpress.com/ https://firejail.wordpress.com/
andai 8mo ago
I was obstinate and refused to learn docker, so I realized I can just rent a $3 VPS. If it blows up the VPS I reset it! Then I realized the only thing I care about on my local machine is "don't touch my files", and Unix users solved that in 1970. So I just run agents as "agent" user. I think running it on a separate machine is nicer though, because it's even simpler and safer than that. (My solution still requires careful setup and regular overhead when you get permission issues. "It's on another laptop, and my stuff isn't" has neither of those problems.)
oliver_dr 8mo ago
[dead]
maciver 8mo ago
[dead]
rex_claw 8mo ago
[dead]
kxrm 8mo ago
This is amazing, thanks for sharing this. I use clippy with rust and the only thing I had to add was: (subpath "/Library/Developer/CommandLineTools")
rishabhaiover 8mo ago
How do you get local sandboxing with a permission based model? I thought wasmtime was the answer!
agent5ravi 8mo ago
[flagged]
babbagegao 8mo ago
[dead]
babbagegao 8mo ago
[dead]
babbagegao 8mo ago
[dead]
bschmidt97979 8mo ago
[dead]
Tadbitrusty 8mo ago
One thing I kept hitting when running agents in sandboxed environments — they lose access to reliable system time too. datetime.now() returns whatever the container thinks, which drifts. Built a small external endpoint for this (SpyderGoat) after an agent made decisions based on completely wrong temporal context. Sandboxing the environment is step one; giving the agent reliable ground truth: for things like time is step two.
croes 8mo ago
The real threat is the agents access to your accounts and services. Why always the fixation on the hardware?
hkonte 8mo ago
[dead]
m3kw9 8mo ago
How’s this different from macOS seatbelt
cowpig 8mo ago
This is awesome! I think this is one of the most important technical hurdles in deploying agent applications right now. I'm involved with a project building something very similar, which we literally open sourced an alpha version of last week: https://github.com/GreyhavenHQ/greywall https://github.com/GreyhavenHQ/greywall It's a bit different in that: - We started with Linux - It is a binary that wraps the agent runtime - It runs alongside a proxy which captures all traffic to provide a visibility layer - Rules can be changed dynamically at runtime I am so happy this problem is getting the attention it deserves!
bhekanik 8mo ago
[dead]
mlysk 8mo ago
Looks like this could be the perfect playground fence around my sandbox in legit-code https://news.ycombinator.com/item?id=46692885 https://news.ycombinator.com/item?id=46692885
CloakHQ 8mo ago
[dead]
webpolis 8mo ago
The macOS sandbox approach is clever, but there's an interesting philosophical split here: sandboxing constrains a local agent, whereas running agents in ephemeral cloud desktops removes the local risk surface entirely. We built Cyqle (https://cyqle.in https://cyqle.in) partly around this idea — each session is a full Linux desktop that's cryptographically wiped on close (AES-256 key destroyed, data unrecoverable). Agents can do whatever they want inside, and the blast radius is zero by design. No residual state, no host OS exposure. The tradeoff is latency and connectivity requirements. For teams already doing cloud-based dev work, it's a natural fit. For local-first workflows where you need offline capability or sub-50ms responsiveness, something like Agent Safehouse makes more sense. Both approaches are worth having — the threat model differs depending on whether you're more worried about data exfiltration or local system compromise.
_slih 8mo ago
cool project but prompt injection doesn't care about your filesystem permissions. the malicious instruction comes from a file the agent is allowed to read.
deleted 8mo ago
[deleted]
snthpy 8mo ago
cco I another option in this space. https://github.com/nikvdp/cco https://github.com/nikvdp/cco
BLACKCRAB 8mo ago
[dead]

823 points by atombender 8mo ago

[flagged]

While we have `sandbox-exec` in macOS, we still don't have a proper Docker for macOS. Instead, the current Docker runs on macOS as a Linux VM which is useful but only as a Linux machine goes. Having real macOS Docker would solve the problem this project solves, and 1001 other problems.

dpe82 8mo ago
Nitpick, which probably doesn't matter too much in this context but is always good to remember: Docker containers are not security boundaries.
- PlasmaPower 8mo ago
  Why not? They're definitely not perfect security boundaries, but neither are VMs. I think containers provide a reasonable security/usability tradeoff for a lot of use cases including agents. The primary concern is kernel vulnerabilities, but if you're keeping your kernel up-to-date it's still imo a good security layer. I definitely wouldn't intentionally run malware in it, but it requires an exploit in software with a lot of eyes on it to break out of.
  - dpe82 8mo ago
    It's certainly better than nothing. Hence "probably doesn't matter too much in this context" - but of course it always matters what your threat model is. Your own agents under your control with aligned models and not interacting with attacker data? Should be fine. But too many people just automatically equate docker with strong secure isolation and... well, it can be, sometimes, depending a hundred other variables. Thus the reminder; to foster conversations like this.
- fredoliveira 8mo ago
  counter-intuitively, the fact that docker on the mac requires a linux-based VM makes it safer than it otherwise would be. But your point stands in general, of course.
mkagenius 8mo ago
Apple containers were released a few months back. Been using it to sandbox claude/gemini-cli generated code[1]. You can use it to completely sandbox claude code too. 1. Coderunner - https://github.com/instavm/coderunner https://github.com/instavm/coderunner
- arianvanp 8mo ago
  That is also Linux VM on MacOS. They're not MacOS containers.. So it's completely pointless / useless for MacOS or iOS development
  - mkagenius 8mo ago
    Oh, yes. I thought GP was mostly worried about shared VM problem.
PufPufPuf 8mo ago
What would native containers bring over Linux ones? The performance of VZ emulation is good, existing tools have great UX, and using a virtualized kernel is a bit safer anyways. I regularly use a Lima VM as a VSCode remote workspace to run yolo agents in.
- hirvi74 8mo ago
  VZ has been exceptional for me. I have been running headless VMs with Lima and VZ for a while now with absolutely zero problems. I just mount a directory I want Claude Code to be able to see and nothing more.
- garganzol 8mo ago
  Sometimes you just have to run native software. In my case, that means macOS build agents using Xcode and Apple toolchains which are only available on macOS. It's not a pleasure to run them in a mutable environment where everything has a floating state as I do now. Native Docker for macOS would totally solve that.
- qalmakka 8mo ago
  > What would native containers bring over Linux ones? What would a Phillips screwdriver bring over a flathead screwdriver? Sometimes you don't want/need the flathead screwdriver, simple as that. There are macOS-specific jobs you need to run in macOS, such as xcode toolchains etc. You can try cross compiling, but it's a pain and ridiculous given that 100% of every other OS supports containers natively (including windows). It's clear to me that Apple is trying to make the ratio jobs/#MacMinis as small as possible
hrmtst93837 8mo ago
[flagged]
egorfine 8mo ago
> Having real macOS Docker would solve the problem I'm very slowly working on a mock docker implementation for macOS that uses ephemeral VM to launch a true guest macOS and perform commands as per Dockerfile/copies files/etc. I use it internally for builds. No public repo yet though. Not sure if there is demand.

xyzzy_plugh 8mo ago

This is just a wrapper around sandbox-exec. It's nice that there are a ton of presets that have been thought out, since 90% of wielding sandbox-exec is correctly scoping it to whatever the inner environment requires (the other 90% is figuring out how sandbox-exec works). I like that it's just a shell script. I do wish that there was a simple way to sandbox programs with an overlay or copy-on-write semantics (or better yet bind mounts). I don't care if, in the process of doing some work, an LLM agent modifies .bashrc -- I only care if it modifies _my_ .bashrc

tuananh 8mo ago
isn't sandbox-exec already deprecated?
- e1g 8mo ago
  Yes, for about a decade. But it’s available everywhere, and still works - and protects us - like brand new!
  - rvz 8mo ago
    It's quite naive to assume that. There is a reason why it is deprecated by Apple. Apple is likely preparing to remove it for a secure alternative and all it takes is someone to find a single or a bunch of multiple vulnerabilities in sandbox-exec to give a wake up call to everyone why were they using it in the first place. I predict that there is a CVE lurking in sandbox-exec waiting to be discovered.
    - TheTon 8mo ago
      On the other hand, the underlying functionality for sandboxing is used heavily throughout the OS, both for App Sandboxes and for Apple’s own system processes. My guess is sandbox-exec is deprecated more because it never was adequately documented rather than because it’s flawed in some way.
      - 8mo ago

gozucito 8mo ago

so this works the same as Claude Code /sandbox? The innovation being that it's harness-agnostic?

arianvanp 8mo ago
That and that the built in sandbox in Claude Code is bad (read only access to everything by default) and tightly coupled (cant modify it or swap it out).
e1g 8mo ago
Roughly, yes, but more reliable (and restrictive), as Claude Code has ways to escape its sandbox. This gives more protection and guards across all CLI agnets (Amp, Pi, etc)

e1g 8mo ago

Creator here - didn't expect this to go public so soon. A few notes: 1. I built this because I like my agents to be local. Not in a container, not in a remote server, but running on my finely-tuned machine. This helps me run all agents on full-auto, in peace. 2. Yes, it's just a policy-generator for sandbox-exec. IMO, that's the best part about the project - no dependencies, no fancy tech, no virtualization. But I did put in many hours to identify the minimum required permissions for agents to continue working with auto-updates, keychain integration, and pasting images, etc. There are notes about my investigations into what each agent needs https://agent-safehouse.dev/docs/agent-investigations/ https://agent-safehouse.dev/docs/agent-investigations/ (AI-generated) 3. You don't even need the rest of the project and use just the Policy Builder to generate a single sandbox-exec policy you can put into your dotfiles https://agent-safehouse.dev/policy-builder.html https://agent-safehouse.dev/policy-builder.html

asabla 8mo ago
Oh woah! I've been trying to get microsandbox to play nicely. But this is much closer to what I actually need. I glimpsed through the site and the script. But couldn't really see any obvious gotchas. Any you've found so far which hasn't been documented yet?
- e1g 8mo ago
  Pure TUI is solid - I’ve been running all my pets inside that cage for several weeks with no issues. Auto-updates work, session renewals work, config updates work etc. But lately I’ve been using agents to test via browsers, and starting headless browsers from the agent is flakey. I’m working on that but it’s hard to find a secure default to run Chrome. In the repo, I have policies for running the Claude desktop app and VSCode inside the same sandbox (so can do yolo mode there too), so there is hope for sandboxing headless Chrome as well.
  - asabla 8mo ago
    Yee I gotcha. Did a migration myself last week from using playwright mcp towards playwright-cli instead. Which has been playing much nicer so far. I guess you would run into the same issues you've already mentioned about running chrome headless in one of these sandboxes. I'll for sure keep an eye out for updates. Kudos to the project!

naomi_kynes 8mo ago

The "full-auto" framing is interesting. What happens when the agent hits something it can't resolve autonomously? Even sandboxed, there's a point where the agent needs to ask a question or get approval. Most setups handle this awkwardly: fire a webhook, write to a log, hope the human is watching. The sandbox keeps the agent contained, but doesn't give it a clean "pause and ask" primitive. The agent either guesses (risky) or silently fails (frustrating). Seems like there are two layers: the security boundary (sandbox-exec, containers, etc.) and the communication boundary (how does a contained agent reach the human?). This project nails the first. The second is still awkward for most setups.

e1g 8mo ago
Correct, this is for skipping permissions (safely), but does nothing for skipping questions.
deleted 8mo ago
[deleted]
_jdtm 8mo ago
[dead]
niyikiza 8mo ago
The two-layer framing is right. Sandbox-exec contains local blast radius, and that's important. But if the agent already has a credential in memory, sandboxing the filesystem doesn't help. I've been working on a primitive for scoped authorization at the tool call level: what was this agent allowed to do, for which task, signed by whom. The core is open-sourced: https://github.com/tenuo-ai/tenuo https://github.com/tenuo-ai/tenuo
jamiemallers 8mo ago
[dead]

tl2do 8mo ago

Intriguing, but... Around last summer (July–August 2025), I desperately needed a sandbox like this. I had multiple disasters with Claude Code and other early AI models. The worst was when Claude Code did a hard git revert to restore a single file, which wiped out ~1000 lines of development work across multiple files. But now, as of March 2026, at least in my experience, agents have become more reliable. With proper guardrails in claude.md and built-in safety measures, I haven't had a major incident in about 3 months. That said, layering multiple safeguards is always recommended—your software assets are your assets. I'd still recommend using something like this. But things are changing, bit by bit.

jeremyjh 8mo ago
Prompt injection attacks are very much a thing. It doesn't matter how good the agent is, its vulnerable, and you don't know what you don't know.
- ramoz 8mo ago
  Where are we at with SOTA or reliable prompt injection detection mechanisms?
e1g 8mo ago
No doubt they are getting better, but even a 0.1% chance of “rm -rf” makes it a question of “when” not “if”. And we sure spin that roulette a lot these days. Safehouse makes that 0%, which is categorically different. Also, I don’t want it to be even theoretically possible for some file in node_modules to inject instructions to send my dotfiles to China.
bilalq 8mo ago
Look into git reflog. If the changes were committed, it was almost certainly possible to still restore them, even if the commit is no longer in your branch.
- ZYbCRq22HbJ2y7 8mo ago
  There are probably other tools like this that keep version history based on filesystem events, independent from the project's git repository https://www.jetbrains.com/help/idea/local-history.html https://www.jetbrains.com/help/idea/local-history.html

synparb 8mo ago

I’ve been playing around with https://nono.sh/ https://nono.sh/ , which adds a proxy to the sandbox piece to keep credentials out of the agent’s scope. It’s a little worrisome that everyone is playing catch up on this front and many of the builtin solutions aren’t good.

vivid242 8mo ago

Nice! I‘d be interesting in the things that went wrong during development. Which loopholes were discovered last, if any?

moehj 8mo ago

[dead]

mkagenius 8mo ago

A way to run claude code inside a apple container - $ container system start $ container run -d --name myubuntu ubuntu:latest sleep infinity $ container exec myubuntu bash -c "apt-get update -qq && apt-get install -y openssh-server" $ container exec myubuntu bash -c " apt-get install -y curl && curl -fsSL https://deb.nodesource.com/setup_lts.x | bash - && apt-get install -y nodejs " $ container exec myubuntu npm install -g @anthropic-ai/claude-code $ container exec myubuntu claude --version

emmelaich 8mo ago
Thanks, hadn't heard of this! In homebrew, too. https://github.com/apple/container https://github.com/apple/container
sunnybeetroot 8mo ago
Lume is also a nice wrapper around it
terhechte 8mo ago
Shuru should do exactly what you want: https://shuru.run https://shuru.run

dbmikus 8mo ago

I like that it's all bash. How does this compare with Codex's and Claude's built-in sandboxing?

e1g 8mo ago
Claude: can escape its sandbox (there are GitHub issues about this) and, when sandboxed, still has full read access to everything on your machine (SSH keys, API keys, files, etc.) Codex: IIRC, only shell commands are sandboxed; the actual agent runtime is not.
- dbmikus 8mo ago
  Cool, thanks for explaining!

pash 8mo ago

Sandvault [0] (whose author is around here somewhere), is another approach that combines sandbox-exe with the grand daddy of system sandboxes, the Unix user system. Basically, give an agent its own unprivileged user account (interacting with it via sudo, SSH, and shared directories), then add sandbox-exe on top for finer-grained control of access to system resources. 0. https://github.com/webcoyote/sandvault https://github.com/webcoyote/sandvault

mikemcquaid 8mo ago
Yeh I came here to post this. I preferred this approach as user permissions are a bit easier to consistently verify as a second layer of defence. I also found the author to be helpful and responsive and the tool to be nicely minimalistic rather than the usual vibe coded ever expanding mess. ‘brew install sandvault’ and running ‘sv’ should get you going. (full disclosure: I created the Homebrew formula and submitted a few PRs to the project)
- TheTaytay 8mo ago
  Means a lot coming from you - thanks for taking the time to post, and for taking the time to make the Homebrew formula. (I am also a fan of the author's (webcoyote's) other work.)

zmmmmm 8mo ago

This is great to see. I honestly think that sandboxing is currently THE major challenge that needs to be solved for the tech to fully realise its potential. Yes the early adopters will YOLO it and run agents natively. It won't fly at all longer term or in regulated or more conservative corporate environments, let alone production systems where critical operations or data are in play. The challenge is that we need a much more sophisticated version of sandboxing than anybody has made before. We can start with network, file system and execute permissions - but we need way more than that. For example, if you really need an agent to use a browser to test your application in a live environment, capture screenshots and debug them - you have to give it all kinds of permissions that go beyond what can be constrained with a traditional sandboxing model. If it has to interact with resources that cost money (say, create cloud resources) then you need an agent aware cloud cost / billing constraint. Somehow all this needs to be pulled together into an actual cohesive approach that people can work with in a practical way.

silverstream 8mo ago
File-level sandboxing is table stakes at this point — the harder problem is credentials and network. An agent inside sandbox-exec still has your AWS keys, GitHub token, whatever's in the environment. I've been running a setup where a local daemon issues scoped short-lived JWTs to agent processes instead of passing raw credentials through, so a confused agent can't escalate beyond what you explicitly granted. Works well for API access. But like you said, nothing at the filesystem level stops an agent from spinning up 50 EC2 instances on your account.
- e1g 8mo ago
  > An agent inside sandbox-exec still has your AWS keys, GitHub token, whatever's in the environment. That's not the case with Agent Safehouse - you can give your agent access to select ~/.dotfiles and env, but by default it gets nothing (outside of CWD)
- ericlevine 8mo ago
  Completely agree. As soon as I had OpenClaw working, I realized actually giving it access to anything was a complete nonstarter after all of the stories about going off the rails due to context limitations [1]. I've been building a self-hosted open sourced tool to try to address this by using an LLM to police the activity of the agent. Having the inmates run the asylum (by having an LLM police the other LLM) seemed like an odd idea, but I've been surprised how effective it's been. You can check it out here if you're curious: https://github.com/clawvisor/clawvisor https://github.com/clawvisor/clawvisor clawvisor.com [1] https://www.tomshardware.com/tech-industry/artificial-intelligence/openclaw-wipes-inbox-of-meta-ai-alignment-director-executive-finds-out-the-hard-way-how-spectacularly-efficient-ai-tool-is-at-maintaining-her-inbox https://www.tomshardware.com/tech-industry/artificial-intell...

nemo44x 8mo ago

Supervisor agent frameworks are going to be a big industry soon. You simply can’t have agents executing commands without a trusted supervisory layer examining and certifying actions. All the issues we get from AI today (hallucinations, goal shift, context decay, etc) get amplified unbelievably fast once you begin scaling agents out due to cascading. The risk being you go to bed and when you wake up your entire infrastructure is gone lol.

gnanagurusrgs 8mo ago

This is the right problem to solve. At Arcade, we see the same gap — agents get shell access, API keys, and network by default. The permissions model is backwards. sandbox-profiles is a solid primitive for local agents. The missing piece in production is the tool layer — even a sandboxed agent can still make dangerous API calls if the MCP tools it has access to aren't individually authed and scoped. The real stack is: sandbox the runtime (what Agent Safehouse does) + scope the tools (what we do with JIT OAuth at the MCP layer). Neither alone is enough. Nice work shipping this. https://www.arcade.dev/blog/ai-agent-auth-challenges-developers https://www.arcade.dev/blog/ai-agent-auth-challenges-develop...

inoki 8mo ago

I'm also working on a cross-platform solution (sandbox-exec on macOS). What if Apple finally drops this after long deprecation?

e1g 8mo ago
Let’s make something so popular and useful that they can’t drop it.

srid 8mo ago

If you are using Nix, there's also https://github.com/srid/sandnix https://github.com/srid/sandnix that works on Linux (landrun) and macOS (sandbox-exec).

cjbarber 8mo ago

See also various sandbox tools I and others (e.g. jpeeler) have collected: https://news.ycombinator.com/item?id=47102258 https://news.ycombinator.com/item?id=47102258

touristtam 7mo ago
Priceless thank you

davidcann 8mo ago

I made a native macOS app with a GUI for sandbox-exec, plus a network sandbox with per-domain filtering and secrets detection: https://multitui.com/ https://multitui.com/

ashishb 8mo ago

I built something similar for myself that works on both Linux and Mac OS https://github.com/ashishb/amazing-sandbox https://github.com/ashishb/amazing-sandbox

devonkelley 8mo ago

[flagged]

varenc 8mo ago

fun fact about `sandbox-exec`, the macOS util this relies on: Apple officially deprecated it in macOS Sierra back in 2016! Its manpage has been saying it's deprecated for a decade now, yet we're continuing to find great uses for it. And the 'App Sandbox' replacement doesn't work at all for use cases like this where end users define their own sandbox rules. Hope Apple sees this usage and stops any plans to actually deprecate sandbox-exec. I recall a bunch of macOS internal services also rely on it.

jasomill 8mo ago
Aside from named profiles, I'm not sure it wasn't born deprecated. In particular, has the profile language ever been documented by anything other than the examples used by the OS and third parties reverse engineering it?
- varenc 8mo ago
  Good point. I have no idea when it was introduced. Would be funny if it's been deprecated since its existence.

simonw 8mo ago

The challenge I'm finding with sandboxes like this is evaluating them in comparison to each other. This looks like a competent wrapper around sandbox-exec. I've seen a whole lot of similar wrappers emerging over the past few months. What I really need is help figuring out which ones are trustworthy. I think this needs to take the form of documentation combined with clearly explained and readable automated tests. Most sandboxes - including sandbox-exec itself - are massively under-documented. I am going to trust them I need both detailed documentation and proof that they work as advertised.

e1g 8mo ago
Thank you for your work - I have sent many of your links to my people. Your point is totally fair for evaluating security tooling. A few notes - 1. I implemented this in Bash to avoid having an opaque binary in the way. 2. All sandbox-exec profiles are split up into individual files by specific agent/integration, and are easily auditable (https://github.com/eugene1g/agent-safehouse/tree/main/profiles https://github.com/eugene1g/agent-safehouse/tree/main/profil...) 3. There are E2E tests validating sandboxing behavior under real agents 4. You don't even need the Safehouse Bash wrapper, and can use the Policy Builder to generate a static policy file with minimal permissions that you can feed to sandbox-exec directly (https://agent-safehouse.dev/policy-builder https://agent-safehouse.dev/policy-builder). Or feed the repo to your LLMs and have them write your own policy from the many examples. 5. This whole repo should be a StrongDM-style readme to copy&paste to your clanker. I might just do that "refactor", but for now added LLM instructions to create your own sandbox-exec profiles https://agent-safehouse.dev/llm-instructions.txt https://agent-safehouse.dev/llm-instructions.txt
- big_toast 8mo ago
  I love this implementation. Do you find the SBPL deficient in any ways? Would xcodebuild work in this context? Presumably I'd watch a log (or have an agent) and add permissions until it works?
  - e1g 8mo ago
    SBPL is great for filesystem controls and I haven’t hit roadblocks yet. I wish it offered more controls of outbound network requests (ie filtering by domain), but I understand why not. Yes, Safehouse should work for xcodebuild workloads in the way you described - try to run it, watch for failures, extend the profile, try again. Your agent can do this in a loop by itself - just feed it the repo as there are many integrations that are not enabled by default that will help it.

matifali 8mo ago

I wonder why you believe that running agents locally is the best approach. For most people, having agents operate remotely is more effective because the agent can stay active without your local machine needing to remain powered on and connected to the internet 24/7.

NegativeLatency 8mo ago
It’s nice having control and ownership of your software. I’m assuming it’s similar to why people run plex, web servers, file sharing, etc Also personally I’d rather not pay monthly fees for stuff if it can be avoided.
- mikodin 8mo ago
  Piggybacking on this - I think it well equips us for a future when local models are stronger. I for one am grateful for efforts like these
- paxys 8mo ago
  These agents are all calling APIs that are well beyond your control. How does it matter whether a thin CLI wrapper is running on your computer or not?
deevus 8mo ago
For this specific problem I built pixels: https://github.com/deevus/pixels https://github.com/deevus/pixels It supports running on a TrueNAS SCALE server, or via Incus (local or remote). I'm still working on tightening the security posture, but for many types of AI workflows it will be more than sufficient.
sunnybeetroot 8mo ago
It’s nice to debug Apple platform projects immediately

Finbarr 8mo ago

Awesome to see a bash-only method of solving this problem. Also like that it alerts on attempts to read restricted stuff. I built yolobox to solve this using docker/apple containers: https://github.com/finbarr/yolobox https://github.com/finbarr/yolobox

sunir 8mo ago

Is clunker some new slang that's different than clanker? I'm asking for a friend of my friend Roku. p.s. thanks for making this; timely as I am playing whackamole with sandboxing right now.

e1g 8mo ago
Testing in prod! Thank you, just fixed that typo.

treexs 8mo ago

wow it's interesting how noticeable sites built with claude maybe with the frotnend-design skill are now

e1g 8mo ago
IYKYK, it’s the new Bootstrap! The alternative would be “no site”, which is still somehow worse.

poopiokaka 8mo ago

[dead]

wek 8mo ago

Do you have plans to go cross-platform and offer a solution for Windows?

hsaliak 8mo ago

This is a very nice and clean implementation. Related to this - I've been exploring injecting landlock and seccomp profiles directly into the elf binary, so that applications that are backed by some LLM, but want to 'do the right thing' can lock themselves out. This ships a custom process loader (that reads the .sandbox section) and applies the policies, not unlike bubblewrap which uses namespaces). The loading can be pushed to a kernel module in the future. https://github.com/hsaliak/sacre_bleu https://github.com/hsaliak/sacre_bleu very rough around the edges, but it works. In the past there were apps that either behaved well, or had malicious intent, but with these LLM backed apps, you are going to see apps that want to behave well, but cannot guarantee it. We are going to see a lot of experimentation in this space until the UX settles!

ClaudioAnthrop 8mo ago
[dead]

boxedemp 8mo ago

Fantastic! I had been using dockers but this might be better!

cuber_messenger 8mo ago

It's the exact auth control I want. However, it seems it's not a safehouse for local agents, but a safe cage, IMHO. After all, it prevents damage they might cause.

alpb 8mo ago

As I understand it, the problem nowadays doesn't seem to be so much that the agent is going to rm -rf / my host, it's more like it's going to connect to a production system that I'm authorized to on my machine or a database tool, and then it's going to run a potentially destructive command. There is a ton of value of running agents against production systems to troubleshoot things, but there are not enough guardrails to prevent destructive actions from the get-go. The solution seems to be specific to each system, and filesystem is just one aspect out of many.

crossroadsguy 8mo ago
As I understand it, the problem is these apps/agents can do all of these and lot more (if not absolutely everything, while I am sure it can go quite close to doing that). Solution could be two parts: OS bringing better and easier to use OS limitations (more granular permissions; install time options and defaults which will be visible to user right there and user can reject that with choices like: - “ask later” - “no” - “fuck no” with eli5 level GUIs (and well documented). Hell, a lot of these are already solved for mobile OS. While not taking away tools away from hands of the user who wants to go inside and open things up (with clear intention and effort; without having to notarise some shit or pay someone). 2. Then apps[1] having to, forced to, adhere to use those or never getting installed. [1] So no treating of agents as some “other” kinds of apps. Just limit it for every app (unless user explicitly decides to open things up). It will also be a great time to nuke the despicable mess like Electron Helpers and shit and app devs considering it completely fine to install a trillion other “things” when user installed just one app without explaining it in the beginning (and hence forced to keep their apps’ tentacles simple and limited)

openclaw01 8mo ago

[dead]

abhisek 8mo ago

I think this is the right approach to building sandbox for agents ie. over existing OS native sandbox capabilities so that they are truly enforced. However the challenge is, sandbox profiles (rules) are always workload specific. How do you define “least privilege” for a workload and then enforce it through the sandbox. Which is why general sandboxes wont be useful or even feasible. The value is observing and probably auto-generating baseline policy for a given workload. Wrong or overly relaxed policies would make sandbox ineffective against real threats it is expected to protect against.

paxys 8mo ago

Not sure I understand this. Agent CLIs already use sandbox-exec, and you can configure granular permissions. You are basically saying - give the agents access to everything, and configure permissions in this second sandbox-exec wrapper on top. But why use this over editing the CLI's settings file directly (e.g. https://code.claude.com/docs/en/sandboxing#configure-sandboxing https://code.claude.com/docs/en/sandboxing#configure-sandbox...)?

scosman 8mo ago
I have sandbox-exec setup for Claude like you suggest, but I’m not sure every CLI supports it? Claude only added it a month or two ago. A wrapper CLI that allows any command to be sandboxed is pretty appealing (Claude config was not trivial). The downside is that it requires access to more than it technically needs (Claude keys for example). I’m working on a version where you sandbox the agent’s Bash tool, not the agent itself. https://github.com/Kiln-AI/Kilntainers https://github.com/Kiln-AI/Kilntainers
- snthpy 8mo ago
  I like the idea but not the MCP part. How about using bash-tool to intercept the commands and then passing them onto the containers? https://github.com/vercel-labs/bash-tool https://github.com/vercel-labs/bash-tool
  - snthpy 8mo ago
    My bad, looks like I misunderstood how bash-tool works. Then how about running Claude Code or your harness of choice inside bubblewrap with a shim/stub for the base binary? https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap
  - scosman 8mo ago
    That's exactly what it does -- the bash commands are passed into the containers. It also manages container lifecycle (starting on first request, cleanup on connection shutdown). If you're using an agent tool that already includes an existing bash tool which calls host OS, just remove that one and add this.

w10-1 8mo ago

But... why not just run macOS in a VM? If/since AI agents work continuously, it seems like running macOS in a VM (via the virtualization framework directly) is the most secure solution and requires a lot less verification than any sandboxing script. (Critical feature: no access to my keychain.) AI agents are not at all like container deploys which come and go with sub-second speed, and need to be small enough that you can run many at a time. (If you're running local inference, that's the primary resource hog.) I'm not too worried about multiple agents in the same vm stepping on each other. I give them different work-trees or directory trees; if they step over 1% of the time, it's not a risk to the bare-metal system. Not sure if I'm missing something...

sunnybeetroot 8mo ago
1 limitation is Apple Virtualisation does not offer USB passthrough for connecting to iPhones for iOS development.
llimllib 8mo ago
For me, it's file system latency on mac os when virtualizing that kills me. Cargo, npm, pip, etc create many small files and there's a high per-file latency on the FS layer

datapolitical 8mo ago

This really is not going to be safe on something like Mac or Windows until it’s built into the OS. But given how fast agents are moving, I would be shocked if such tools were not already being built

ai_fry_ur_brain 8mo ago

Docker...

Agent_Builder 8mo ago

[dead]

grun 8mo ago

similar project https://github.com/trailofbits/claude-code-devcontainer https://github.com/trailofbits/claude-code-devcontainer

ashniu123 8mo ago

How's this different from https://container-use.com https://container-use.com?

sagarpatil 8mo ago

Looks good. I’ll give it a try.

jeff_antseed 8mo ago

[dead]

edf13 8mo ago
We are a different approach and are targeting Linux for our first release (Windows & Mac shortly afterwards). Taking more of an automated supervisor approach with limited manual approval for edge cases. Grith.ai
carderne 8mo ago
There is sandbox-runtime [1] from Anthropic that uses bubblewrap to sandbox on Linux (and works the same as OP on macOS). You can look at the code to see how it uses it. Anthropic's tool only support read blacklist, not a whitelist, so I forked it yesterday to support that [2]. [1] https://github.com/anthropic-experimental/sandbox-runtime https://github.com/anthropic-experimental/sandbox-runtime [2] https://github.com/carderne/sandbox-runtime https://github.com/carderne/sandbox-runtime

carderne 8mo ago

How do agents tend to deal with getting blocked? Messing around with sandboxes, I've quite even seen them get blocked, assume something is wrong, and go _crazy_ trying to get around the block, never stopping to ask for user input. It might be good to add to the error message: "This is deliberate, don't try to get around it." For those using pi, I've built something similar[1] that works on macOS+Linux, using sandbox-exec/bubblewrap. Only benefit over OP is that there's some UX for temporarilily/permanently bypassing blocks. [1] https://github.com/carderne/pi-sandbox https://github.com/carderne/pi-sandbox

e1g 8mo ago
Claude Code and Codex quickly figure out they are inside sandbox-exec environment. Maybe because they know it internally. Other agents often realize they are being blocked, and I haven't seen them go haywire yet. Big love for Pi - it was the first integration I added to Safehouse. I wanted something that offers strong guarantees across all agents (I test and write them nonstop), has no dependencies (e.g., the Node runtime), and is easy to customize, so I didn't use the Anthropic sandbox-runtime.
- carderne 8mo ago
  Interesting, that's not been my experience! Maybe you've got the list of things to allow/block just right. While testing different policies I've frequently seen Opus 4.6 go absolutely nuts trying to get past a block, unless I made it more clear what was happening. Yeah I think for general use the transparency of what your thing does is really great compared to a pile of TypeScript and whatnot.
gbrindisi 8mo ago
ah I also did my own sandbox and at least twice the agent inside tried really hard to go around the firewall, so I ended up intercepting calls to `connect` to return a message that says "Connection refused by the sandbox, don't try to bypass". Code here: https://github.com/gbrindisi/agentbox https://github.com/gbrindisi/agentbox

SiteMgrAI 8mo ago

Sandboxing is going to be table stakes for any serious deployment of AI agents in regulated industries. In sectors like construction, healthcare, or finance, you cannot have an agent with unrestricted filesystem or network access making decisions that affect safety-critical documentation. The macOS sandbox approach is smart because it leverages the OS-level enforcement rather than relying on application-layer restrictions that an agent could potentially reason its way around. The real question is how you balance useful tool access with meaningful containment when the whole point of agents is autonomous action.

brutuscat 8mo ago

What do you think of sandbox-exec being marked as deprecated? https://news.ycombinator.com/item?id=31973232 https://news.ycombinator.com/item?id=31973232 https://github.com/openai/codex/issues/215 https://github.com/openai/codex/issues/215

yowang 8mo ago

[dead]

octoclaw 8mo ago

[dead]

ptak_dev 8mo ago

[flagged]

brap 8mo ago
I think these are 2 independent axis: 1. Destructive by accident 2. Destructive because it was prompt-injected And 1. Fucks up filesystem 2. Fucks up external systems via credentials
eelke 8mo ago
Problem 2 is mitigated by only allowing trusted sources through firewall rules.
tcbrah 8mo ago
problem 2 is actually scarier than most people realize because it compounds. your agent reads a README in some dependency, that README has injection instructions, now the agent is acting on behalf of the attacker with whatever permissions you gave it. filesystem sandboxing doesnt help because the dangerous action might be "write a backdoor into the file i already have write access to" which is completely within the sandbox rules. the short-lived scoped credentials approach someone mentioned upthread is probably the best practical mitigation right now. but even that breaks down when the agent legitimately needs broad access to do its job - like if its refactoring across a monorepo it kinda needs write access to everything. i think the actual answer long term is something closer to capability-based security where each tool call gets its own token scoped to exactly what that specific action needs. but nobody has built that yet in a way that doesnt make the agent 10x slower.
wilkystyle 8mo ago
Matchlock[0] is probably the best solution I've come across so far WRT problem 1 and 2: > Matchlock is a CLI tool for running AI agents in ephemeral microVMs - with network allowlisting, secret injection via MITM proxy, and VM-level isolation. Your secrets never enter the VM. In a nutshell, it solves problem #2 through a combination of a network allowlist and secret masking/injection on a per-host basis. Secrets are never actually exposed inside the sandbox. A placeholder string is used inside the sandbox, and the mitm proxy layer replaces the placeholder string with the actual secret key outside of the sandbox before sending the request along to its original destination. Furthermore, because secrets are available to the sandbox only on a per-host basis, you can specify that you want to share OPENAI_API_KEY only with api.openai.com, and that is the only host for which the placeholder string will be replaced with the actual secret value. edit to actually add the link [0] https://github.com/jingkaihe/matchlock https://github.com/jingkaihe/matchlock

guimbuilds 8mo ago

Interesting, we're tackling a different layer of the same problem, snapshot before every run + one-click rollback instead of kernel sandboxing. Complementary approaches. Nice work.

devrimozcay 8mo ago

Interesting direction. One thing we've been seeing with production AI agents is that the real risk isn't just filesystem access, but the chain of actions agents can take once they have tool access. Even a simple log-reading capability can escalate if the agent starts triggering automated workflows or calling internal APIs. We've been experimenting with incident-aware agents that detect abnormal behavior and automatically generate incident reports with suggested fixes. Curious if you're thinking about integrating behavioral monitoring or anomaly detection on top of the sandbox layer.

rwky 8mo ago

Fore Linux firejail works well https://firejail.wordpress.com/ https://firejail.wordpress.com/

andai 8mo ago

I was obstinate and refused to learn docker, so I realized I can just rent a $3 VPS. If it blows up the VPS I reset it! Then I realized the only thing I care about on my local machine is "don't touch my files", and Unix users solved that in 1970. So I just run agents as "agent" user. I think running it on a separate machine is nicer though, because it's even simpler and safer than that. (My solution still requires careful setup and regular overhead when you get permission issues. "It's on another laptop, and my stuff isn't" has neither of those problems.)

oliver_dr 8mo ago

[dead]

maciver 8mo ago

[dead]

rex_claw 8mo ago

[dead]

kxrm 8mo ago

This is amazing, thanks for sharing this. I use clippy with rust and the only thing I had to add was: (subpath "/Library/Developer/CommandLineTools")

rishabhaiover 8mo ago

How do you get local sandboxing with a permission based model? I thought wasmtime was the answer!

agent5ravi 8mo ago

[flagged]

babbagegao 8mo ago

[dead]

babbagegao 8mo ago

[dead]

babbagegao 8mo ago

[dead]

bschmidt97979 8mo ago

[dead]

Tadbitrusty 8mo ago

One thing I kept hitting when running agents in sandboxed environments — they lose access to reliable system time too. datetime.now() returns whatever the container thinks, which drifts. Built a small external endpoint for this (SpyderGoat) after an agent made decisions based on completely wrong temporal context. Sandboxing the environment is step one; giving the agent reliable ground truth: for things like time is step two.

croes 8mo ago

The real threat is the agents access to your accounts and services. Why always the fixation on the hardware?

hkonte 8mo ago

[dead]

m3kw9 8mo ago

How’s this different from macOS seatbelt

cowpig 8mo ago

This is awesome! I think this is one of the most important technical hurdles in deploying agent applications right now. I'm involved with a project building something very similar, which we literally open sourced an alpha version of last week: https://github.com/GreyhavenHQ/greywall https://github.com/GreyhavenHQ/greywall It's a bit different in that: - We started with Linux - It is a binary that wraps the agent runtime - It runs alongside a proxy which captures all traffic to provide a visibility layer - Rules can be changed dynamically at runtime I am so happy this problem is getting the attention it deserves!

bhekanik 8mo ago

[dead]

mlysk 8mo ago

Looks like this could be the perfect playground fence around my sandbox in legit-code https://news.ycombinator.com/item?id=46692885 https://news.ycombinator.com/item?id=46692885

CloakHQ 8mo ago

[dead]

webpolis 8mo ago

The macOS sandbox approach is clever, but there's an interesting philosophical split here: sandboxing constrains a local agent, whereas running agents in ephemeral cloud desktops removes the local risk surface entirely. We built Cyqle (https://cyqle.in https://cyqle.in) partly around this idea — each session is a full Linux desktop that's cryptographically wiped on close (AES-256 key destroyed, data unrecoverable). Agents can do whatever they want inside, and the blast radius is zero by design. No residual state, no host OS exposure. The tradeoff is latency and connectivity requirements. For teams already doing cloud-based dev work, it's a natural fit. For local-first workflows where you need offline capability or sub-50ms responsiveness, something like Agent Safehouse makes more sense. Both approaches are worth having — the threat model differs depending on whether you're more worried about data exfiltration or local system compromise.

_slih 8mo ago

cool project but prompt injection doesn't care about your filesystem permissions. the malicious instruction comes from a file the agent is allowed to read.

deleted 8mo ago

[deleted]

snthpy 8mo ago

cco I another option in this space. https://github.com/nikvdp/cco https://github.com/nikvdp/cco

BLACKCRAB 8mo ago

[dead]