SandVault: a second macOS user account plus sandbox-exec as an agent boundary

The problem SandVault addresses: agents that write wherever they can

A coding agent runs as your user. That means it inherits your home directory, your SSH keys, your cloud credentials and every mounted volume. The README frames SandVault as a lightweight alternative to application isolation using virtual machines, and the pitch is speed rather than maximum containment: no VM overhead, instant user switching, passwordless after setup. The intended audience is a Mac developer who wants to point an agent at a repository without handing it the rest of the machine. The README lists Claude Code, OpenAI Codex, OpenCode, Google Gemini, pi and Muse Code as ready-made entry points, and the shell subcommand covers arbitrary commands. It is a boundary for agent overreach, not a hardened jail against a local adversary who already has code execution.

Two layers: a limited user account and a sandbox-exec profile

SandVault does not implement its own syscall filter. It combines an ordinary macOS user, named sandvault-$USER, with the system's sandbox-exec facility. The default mode is described as basically sudo -u sandbox-$USER COMMAND. The security model section lists what the sandbox can reach: writable /Users/Shared/sv-$USER for shared work, writable /Users/sandvault-$USER as the account's home, readable /usr, /bin, /etc and /opt, no access to /Users/*, writable /Volumes/Macintosh HD subject to file permissions, and no access to /Volumes/*, which covers mounted, remote and network drives. Read that list carefully, because the boot volume remains writable at the permission level. The sandbox account runs with standard user privileges and cannot modify system files, so the practical containment comes from Unix file ownership plus the profile, not from a hypervisor. Anything owned by your primary account under /Users is out of reach, which is the whole point.

Getting it running: brew, git clone, and the sv aliases

The documented install paths are Homebrew (brew install sandvault) or a git clone with the directory added to PATH, or an alias such as alias sv="/path/to/where/you/cloned/sandvault/sv". From there the entry points are short: sv claude, sv codex, sv opencode, sv gemini, sv pi, sv muse, sv shell. Shortcuts exist, so sv cl maps to Claude Code and sv s to the shell. Agents take arguments after a double dash, as in sv gemini -- --continue. The shell form accepts a working directory and a command: sv shell /Users -- pwd, and stdin piping works, for example cat PROMPT.md | sv gemini or echo "pwd ; exit" | sv shell /Users. sv-clone URL_OR_LOCAL_PATH [-- SV_ARGS] clones a repository into /Users/Shared/sv-$USER/repos/<git-repository> and starts an agent there. For local repositories it also wires a remote named sandvault pointing back at that clone, so git fetch sandvault from your original checkout pulls commits the agent made inside.

SSH mode, authorized_keys.d and the build step

The default impersonation mode can be swapped for SSH with sv --ssh gemini, which runs ssh sandbox-$USER@127.0.0.1 under the hood. Key management is file-based and explicit. You drop each public key into its own file under ~/.config/codeofhonor/sandvault/authorized_keys.d/, then run any sv command to apply it; the README uses sv build as the example. Those files are the source of truth: sandvault regenerates the sandvault user's authorized_keys from them plus its own key on every run, so deleting a file revokes that key on the next run. Two failure modes are documented rather than hidden. Files that are not SSH public keys are ignored with a warning, and a private key left in that directory stops the build instead of being copied into the sandbox. The regeneration-on-every-run behaviour means you should treat that directory as configuration, not as a scratch space for keys you plan to keep.

Where the isolation stops: GUI apps, volumes and the install path

The README states plainly that it is not possible to run GUI applications from within the sandbox, and points to a Running GUI Applications section for the workarounds. That rules out anything that needs a window server session, which matters if your agent workflow depends on a GUI editor, a browser you drive by hand, or a signed-in desktop app. Mounted, remote and network drives are unreachable, so an agent cannot touch an external SSD or an SMB share. The boot volume stays writable as per file permissions, so the boundary is ownership-based and depends on your files being owned by your primary account. There is also an install-path decision: by default SandVault installs AI tools via Homebrew on the host side, and with --native-install (or -N) it installs them inside the sandbox using each vendor's own installer, for example curl -fsSL https://claude.ai/install.sh | bash for Claude Code or npm install -g @openai/codex for Codex. The README notes native tools are installed on first run and reused afterwards, and that SANDVAULT_ARGS can make native install the default. Which path you pick changes where the binaries live and therefore what the sandbox profile has to allow.

Compared with running the agent in a VM or container

The obvious alternative is a virtual machine or a Linux container. A VM gives you a separate kernel, so the agent's process cannot reach your Mac's filesystem at all except through whatever share you mount, and the same is true of a container on a Linux host with a bind-mounted project directory. SandVault's approach is different in kind: the agent is a process on your machine, running as a second local user, filtered by sandbox-exec and by Unix ownership. That buys near-instant startup and passwordless switching, and it costs you the kernel boundary. A sandbox-exec escape or a flaw in the profile is a flaw in your running system, not in a disposable guest. If your threat model is a curious or over-eager agent, the user account is a reasonable trade. If it is untrusted code chosen by someone else, the VM remains the stronger answer, and SandVault does not claim otherwise.

Maintenance, uninstall and licence

The README advertises clean uninstall via sv uninstall, which matters because SandVault creates a real user account, a shared directory at /Users/Shared/sv-$USER, a home at /Users/sandvault-$USER and an SSH configuration directory under ~/.config/codeofhonor/sandvault. Upgrade cost is mostly the cost of the agents themselves. With the default Homebrew install, agent updates follow your normal brew workflow; with --native-install, each tool updates through its own installer, so you inherit six different update mechanisms. The repository is Shell, the licence is Apache-2.0, and no releases were retrieved, so there is no tagged version to pin against. Apache-2.0 permits commercial use and modification and includes a patent grant; it also requires that you keep the licence and notice files when redistributing. That is a summary of the licence text, not legal advice, and if you plan to redistribute a modified SandVault you should read the full terms yourself.

Editorial conclusion

Adopt SandVault if you already run Claude Code, Codex, OpenCode, Gemini, pi or Muse Code on a Mac and want the agent's file writes confined to /Users/Shared/sv-$USER. Do not adopt it if you need GUI applications inside the sandbox, access to mounted or network volumes, or isolation against a determined local attacker rather than a misbehaving agent. Verify first that sandbox-exec is still permitted on your macOS build, that your agents run under the default Homebrew path or that you pass --native-install, and that your sensitive material lives outside /Users/Shared/sv-$USER.

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. webcoyote/sandvault on GitHub