[HN Gopher] Agent Safehouse - macOS-native sandboxing for local ...
___________________________________________________________________
Agent Safehouse - macOS-native sandboxing for local agents
Author : atombender
Score : 164 points
Date : 2026-03-08 20:30 UTC (2 hours ago)
(HTM) web link (agent-safehouse.dev)
(TXT) w3m dump (agent-safehouse.dev)
| garganzol wrote:
| 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 wrote:
| Nitpick, which probably doesn't matter too much in this context
| but is always good to remember: Docker containers are not
| security boundaries.
| PlasmaPower wrote:
| 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.
| fredoliveira wrote:
| 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 wrote:
| 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
| arianvanp wrote:
| That is also Linux VM on MacOS. They're not MacOS
| containers.. So it's completely pointless / useless for MacOS
| or iOS development
| mkagenius wrote:
| Oh, yes. I thought GP was mostly worried about shared VM
| problem.
| PufPufPuf wrote:
| 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 wrote:
| 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 wrote:
| 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.
| xyzzy_plugh wrote:
| 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
| e1g wrote:
| Thanks, I picked Bash because I'm scared of all Go and Rust
| binaries out there!
|
| Re "overlay FS" - I too wish this was possible on Macs, but the
| closest I got was restricting agents to be read-only outside of
| CWD which, after a few turns, bullies them into working in
| $TMP. Not the same though.
| divmain wrote:
| This is what I was going for with Treebeard[0]. It is sandbox-
| exec, worktrees, and COW/overlay filesystem. The overlay
| filesystem is nice, in that you have access to git-ignored
| files in the original directory without having to worry about
| those files being modified in the original (due to the COW
| semantics). Though, truthfully, I haven't found myself using it
| much since getting it all working.
|
| [0] https://github.com/divmain/treebeard
| xyzzy_plugh wrote:
| This approach is too complex for what is provided. You're
| better off just making a copy of the tree and simply using
| sandbox-exec. macFUSE is a shitshow.
|
| The main issue I want to solve is _unexpected_ writes to
| arbitrary paths should be allowed but ultimately discarded.
| macOS simply doesn 't offer a way to namespace the filesystem
| in that way.
| dbmikus wrote:
| I've been working on an OSS project, Amika[1], to quickly spin
| up local or remote sandboxes for coding workloads. We support
| copy-on-write semantics locally (well, "copy-and-then-write"
| for now... we just copy directories to a temp file-tree).
|
| It's tailored to play nicely with Git: spin up sandboxes form
| CLI, expose TCP/UDP ports of apps to check your work, and if
| running hosted sandboxes, share the sandbox URLs with
| teammates. I basically want running sandboxed agents to be as
| easy as `git clone ...`.
|
| Docs are early and edges are rough. This week I'm starting to
| dogfood all my dev using Amika. Feedback is super appreciated!
|
| FYI: we are also a startup, but local sandbox mgmt will stay
| OSS.
|
| [1]: https://github.com/gofixpoint/amika
| gozucito wrote:
| so this works the same as Claude Code /sandbox? The innovation
| being that it's harness-agnostic?
| arianvanp wrote:
| 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 wrote:
| 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 wrote:
| 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/ (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
| asabla wrote:
| 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 wrote:
| 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 wrote:
| 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!
| TheBengaluruGuy wrote:
| I'm wondering if this could be adapted for openclaw. Running it
| in a machine that's accessible reduces friction and enables a
| lot of use-cases but equally hard to control/restrict it
| atombender wrote:
| OP here. Sorry if this was premature. I came across it through
| your earlier comment on HN, started using it (as did a
| colleague), and we've been impressed enough with how efficient
| it is that I decided it deserved a post!
|
| I've seen sandbox policy documents for agents before, but this
| is the first ready-to-use app I've come across.
|
| I've only had a couple of points of friction so far:
|
| - Files like .gitconfig and .gitignore in the home folder
| aren't accessible, and can't be made accessible without
| granting read only access to the home folder, I think?
|
| - Process access is limited, so I can't ask Claude to run lldb
| or pkill or other commands that can help me debug local
| processes.
|
| More fine-grained control would be really nice.
| e1g wrote:
| Love the feedback -
|
| For handling global rules (like ~/.gitconfig and
| ~/.gitignore), I keep a local policy file that whitelists my
| "shared globals" paths, and I tell Safehouse to include that
| policy by default. I just updated the README with an example
| that might be useful[1]. I also enabled access to
| ~/.gitignore by default as it's a common enough default.
|
| For process management, there is a blurry line about how much
| to allow without undermining the sandboxing concept. I just
| added new integrations[2] to allow more process control and
| lldb, but I don't know this area well. You can try cloning
| the repo, asking your agents to tweak the rules in the repo
| until your use-case works, and send a PR - I'll merge it!
|
| Alternatively, using the "custom policy" feature above, you
| can selectively grant broad access to your tools (you can use
| log monitoring to see rejections, and then add more
| permisions into the policy file)
|
| [1] https://github.com/eugene1g/agent-safehouse?tab=readme-
| ov-fi...
|
| [2] https://github.com/eugene1g/agent-safehouse/pull/7
| naomi_kynes wrote:
| 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 wrote:
| Correct, this is for skipping permissions (safely), but does
| nothing for skipping questions.
| tl2do wrote:
| 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 wrote:
| 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 wrote:
| Where are we at with SOTA or reliable prompt injection
| detection mechanisms?
| e1g wrote:
| 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 wrote:
| 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.
| synparb wrote:
| I've been playing around with 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 wrote:
| Nice! I'd be interesting in the things that went wrong during
| development. Which loopholes were discovered last, if any?
| mkagenius wrote:
| 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
| dbmikus wrote:
| I like that it's all bash.
|
| How does this compare with Codex's and Claude's built-in
| sandboxing?
| e1g wrote:
| 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.
| pash wrote:
| Sandvault [0] (whose author is around here somewhere), is another
| approach based on sandbox-exe, but that additionally uses the
| good old Unix user system for further isolation.
|
| 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 resource-specific permissions and
| another layer of isolation.
|
| 0. https://github.com/webcoyote/sandvault
| zmmmmm wrote:
| 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.
___________________________________________________________________
(page generated 2026-03-08 23:00 UTC)