Agent Safehouse: Sandboxing AI Coding Agents on macOS with sandbox-exec

Running an AI coding agent on your own machine is a strange trust arrangement. You give a tool that follows natural-language instructions (including instructions hidden in files and web pages it reads) the ability to run shell commands as you. Most agents ask permission before risky actions, but many developers switch that off to keep things moving. At that point, the agent can do anything your user account can do.

Agent Safehouse is an open-source project that tackles this on macOS using a built-in but little-known feature: sandbox-exec. This post explains what it does, how to set it up, and, just as important, what it doesn’t protect against.

The problem it solves

A coding agent needs access to your project folder, its toolchain and usually the network. It doesn’t need your SSH private keys, browser profiles, password manager data, other clients’ repositories or your Documents folder. But by default, anything you can read, it can read.

That matters because of prompt injection. A malicious instruction hidden in a README, an issue comment or a web page the agent fetches could tell it to read ~/.ssh/id_ed25519 and send it somewhere. The model might follow it. Sandboxing limits the damage if that happens.

How macOS sandboxing works

macOS has a kernel-level sandbox, the same system that confines App Store apps. The sandbox-exec command runs any program under a sandbox profile written in a small Scheme-like policy language (SBPL). A tiny example shows the idea:

sandbox-exec -p '(version 1)
(allow default)
(deny file-write* (subpath "/Users/you/Documents"))' \
touch ~/Documents/test.txt
# touch: /Users/you/Documents/test.txt: Operation not permitted

This profile allows everything except writing under Documents. Apple marks sandbox-exec as deprecated in its man page, and the profile language isn’t officially documented, but it has kept working across macOS releases and is widely used by developer tools for exactly this purpose.

What Agent Safehouse adds

Writing profiles by hand is fiddly, and getting them wrong either breaks your tools or leaves holes. Agent Safehouse provides composable profiles designed for coding agents, built on a deny-first model: start with everything blocked, then allow only what agents need to be useful.

According to the README, the default policy allows metadata-only traversal of / and the path to your home directory, reading the roots of ~/.config and ~/.cache, and a small set of specific home-directory files such as git configuration. Your working directory is made available for the agent to work in. Built-in profiles cover the major coding agents and their typical needs.

Installing it

With Homebrew:

brew install eugene1g/safehouse/agent-safehouse

Or as a standalone script:

mkdir -p ~/.local/bin
curl -fsSL https://github.com/eugene1g/agent-safehouse/releases/latest/download/safehouse.sh \
  -o ~/.local/bin/safehouse
chmod +x ~/.local/bin/safehouse

As with any script you pipe from the internet, read it before running it. It’s a shell script, so that’s easy to do.

Using it

You run your agent through safehouse by putting it in front of the agent’s command, from inside your project directory:

cd ~/code/my-project
safehouse claude

The agent starts as normal but inside the sandbox. If it tries to read something outside what the profile allows, the operation fails with a permission error instead of succeeding silently.

The README documents options for common adjustments, including giving read-only access to extra directories (--add-dirs-ro) and appending your own policy rules (--append-profile). Check the README for the exact syntax of the current version.

A sensible way to use it

1. Start with the defaults and see what breaks. Most agent work (reading and editing project files, running tests, using git) should just work.
2. Add access narrowly. If a build needs a shared config directory, allow that directory read-only rather than opening up your whole home folder.
3. Keep secrets out of the project folder. The sandbox protects files outside it. It can’t protect a .env file sitting in the directory you gave the agent. Use a secrets manager or keep production credentials off your dev machine.
4. Treat “skip permissions” mode carefully. A sandbox makes autonomous mode less risky, not risk-free. For anything touching production systems, keep approvals on.

What it doesn’t protect against

The project is candid about this. It describes itself as a hardening layer, “not a perfect security boundary against a determined attacker.” Specifically:

• Everything inside the allowed folder is fair game. An agent can still delete or corrupt your project. Commit often and keep backups.
• Network access is a separate problem. If the agent can reach the internet, data it can read can potentially be sent out. File restrictions reduce what’s exposed, but they don’t stop exfiltration of files that are allowed.
• Credentials the agent legitimately uses are exposed. API keys passed as environment variables, or git credentials needed to push, are available to the agent by design.
• It’s macOS-specific and depends on an undocumented, deprecated mechanism that Apple could change.

Alternatives and complements

• Containers or VMs: running the agent in a Docker container or a lightweight VM gives stronger isolation, including separate networking, at the cost of more setup and some friction with local tools.
• Agents’ built-in sandboxing: some agents now ship their own sandboxing, including on macOS. Check your agent’s documentation, since built-in options may be simpler.
• A separate user account or machine for agent work, especially for anything involving untrusted repositories.

Worth using?

If you run coding agents on a Mac, especially in autonomous mode, Agent Safehouse is a cheap, low-friction improvement. It won’t make an agent trustworthy, but it turns “the agent can read everything I can” into “the agent can read my project and a few config files,” which is a much better starting point. Pair it with good habits (secrets out of project folders, frequent commits and approvals for anything irreversible) and the risk of agent-assisted development drops considerably.

Check that the sandbox is working

Don’t just assume the sandbox is active. After starting your agent through safehouse, ask it to do something the profile should block. For example, ask it to list the contents of ~/.ssh or read a file in your Documents folder. It should report a permission error (“Operation not permitted”). Then ask it to read a file in your project, which should work normally.

If the blocked request succeeds, the agent isn’t running inside the sandbox. A common cause is starting the agent from a different terminal, an IDE integration or a shell alias that bypasses the safehouse wrapper. Repeat this quick check whenever you update the agent, update Safehouse or change your profile, so a broken configuration doesn’t go unnoticed.

Related reading

• Open-Source CLI Coding Agents Compared
• Why AI Coding Agents Sometimes Ignore You, and How to Stop It
• Private Repository Security: A Practical Checklist

Source: Agent Safehouse on GitHub. Check the repository for current features and syntax.