Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agent Safehouse – macOS-native sandboxing for local agents

agent-safehouse.dev

Post reply on HN
Print view View original

191–200 of 207 posts

Re: Agent Safehouse – macOS-native sandboxing for local agents

#193

Post by scosman »

quietsegfault wrote: post #157
scosman wrote: post #128

Earlier quoted context omitted.

Apple APIs yes. But there’s also an overhead when running containers like docker on Mac (and windows). Only Linux has near-zero overhead.

Right, because on Mac (and windows) you’re running a VM rather than just setting up kernel namespaces. How cpu and network intensive are these pets? Or is it more of a principle thing, which I totally understand? I prefer containerization because it gives me a repeatable environment that I know works, where on my system things can change as the os updates and applications evolve. But I can understand the benefit of s…

very roughly: not that bad but not zero. I see docker taking a continuous 1/2% CPU on MacOS when running its host, where sandbox-exec or containers on linux are zero unless used.

If you prefer containers, use containers.

Re: Agent Safehouse – macOS-native sandboxing for local agents

#195

Post by webpolis »

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

Re: Agent Safehouse – macOS-native sandboxing for local agents

#197

Post by e1g »

big_toast wrote: post #187
e1g wrote: post #136

Earlier quoted context omitted.

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 integ…

For anyone reading this later. I read a little from sandvault and they suggest sandbox-exec doesn't allow recursive sandboxing, so you need to set flags on xcodebuild and swift to not sandbox in addition to the correct SBPL policy. (I don't think sandvault has a swift/xcode specific policy because they're dumping everything into a sandvault userspace. And it doesn't really concern itself with networking afaict either…

Yes, you're correct about 'no nested sandboxing'.

This also applies to sandboxing an Electron app: Electron has its own built-in sandboxing via sandbox-exec, so if you're wrapping an Electron app in your own sandboxing, you have to disable that inner sandbox (with Electron's --no-sandbox or ELECTRON_DISABLE_SANDBOX=1). In the repo, I have examples for minimal sandbox-exec rules required to run Claude Code[1] and VSCode[2] (so you can do --dangerously-skip-permission in their destop app and VSCode extension)

[1] https://github.com/eugene1g/agent-safehouse/blob/a7377924efa...

[2] https://github.com/eugene1g/agent-safehouse/blob/a7377924efa...

Re: Agent Safehouse – macOS-native sandboxing for local agents

#199

Post by snthpy »

scosman wrote: post #131
paxys wrote: post #101

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-sandbox... )?

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 ag…

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

Re: Agent Safehouse – macOS-native sandboxing for local agents

#200

Post by snthpy »

snthpy wrote: post #199
scosman wrote: post #131

Earlier quoted context omitted.

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 ag…

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

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

Post reply on HN