Sandboxes and Worktrees: My secure Agentic AI Setup | Mike McQuaid

Mike McQuaid

CTPO and Homebrew Project Leader

Articles

Talks

Interviews

Thoughts

Projects

CV

Now

About

Sandboxes and Worktrees: My secure Agentic AI Setup

14 April 2026

I’ve been using AI tools since early 2021 when I was invited to test out the Copilot internal alpha at GitHub (where I spent 10 years).<br>I’ve maintained Homebrew since 2009.<br>I’ve now personally hit the “AI writes 90% of my code” (Dario Amodei’s early 2025 prediction for late 2025).<br>I’ve been asked by a few folks to detail my current setup so: here it is.

TL;DR:

Agents bring a step change from code completion to code generation and are good enough now to one-shot many problems

Sandboxing improves security and productivity by letting agents run wild without babysitting permission prompts

Git worktrees parallelise work so more tokens/spend directly translates to more velocity

🤖 Agents

If you’re still using AI in “code completion mode” or only GitHub Copilot, you’re missing out.<br>Mid-to-late 2025 was when agentic tools like Claude Code and OpenAI Codex got good enough that prompting became quicker than editing, even when you’re anal about it.

My experience of Claude Code and OpenAI Codex has mostly been:

OpenAI Codex (5.4 xhigh): takes a while, generally does things mostly right first time, doesn’t need much prompting/steering

Claude Code (Opus 4.6 max): fairly stupid by default, can be nudged with aggressive hooks/tools/prompts to being less so

(Opus 4.7 just got released: let’s see if it’s less stupid…)

My daily driver of choice is OpenAI Codex but I run out of tokens more quickly so have learned to be fine with either.<br>(OpenAI: please give me the free tokens I’ve applied for as an OSS maintainer, thanks A lot of people spend a lot of time and energy thinking about their CLAUDE.md/AGENTS.md.<br>My experience is their performance varies so much from model to model, version to version that it’s worth keeping them as minimal as possible.<br>I have an AGENTS-GLOBAL.md in my dotfiles that provides a decent minimum of what I care about across all projects in Claude and Codex.

The main problem you’ll bump into pretty quickly with agents is: you have to spend half your life going “Yes, do this safe thing”, “No, don’t do this dangerous thing”.<br>This is boring and slow.<br>I’m lazy so needed better automation.

🏝️ Sandvault

The various agents have various “bypass permission checks”, “run without sandbox”, “YOLO”, etc. modes.

If you want to be actually productive with these tools you basically have two options:

decide you’re just going to play with fire and disable permissions and hope nothing goes wrong

run in a sandboxed environment e.g. a VM, separate machine, sandbox with reduced (system) permissions, access, tokens, etc.

I picked option 2 because I take my responsibility as a Homebrew maintainer seriously to not do stupid insecure shit on my machine.<br>Unfortunately, also because I’m a Homebrew maintainer, I’m allergic to using Docker for local macOS development.

sandvault is the nicest middle ground I’ve come across.<br>It makes use of macOS sandboxes and creates and maintains a separate non-admin user account where you can let it run wild.<br>Short of exfiltrating your code (which I’m not worried about with OSS), it closes the majority of risk vectors I care about where agents might:

go e.g. rm -rf on files not in version control

use my e.g. GITHUB_TOKEN to do things on sensitive repositories

exfiltrate sensitive files elsewhere

Once installed (brew install sandvault), you can run sv codex or sv claude to start your agent of choice or sv shell to start a shell.

You can also put your dotfiles under /Users/Shared/sv-${USER}/user and they will be copied to the relevant sandvault e.g. (sandvault-mike) user.

Take a look at my dotfiles’ script/sync if you want an example of how to do this.

I also recommend using a different-coloured prompt for your Sandvault user so you know when you’re inside it.<br>See my dotfiles shprofile.sh and zprofile.sh for examples.

🤝 Sharing

This all works nicely but: what if you want to share code more easily between your current $USER (e.g. mike) and the unprivileged sandvault (e.g. sandvault-mike) user?

I would normally clone all my OSS repositories into ~/OSS/* and employer’s (currently Administrate) into e.g. ~/Administrate.<br>Instead, I now clone under the Sandvault-created /Users/Shared/sv-mike into /Users/Shared/sv-mike/repositories and create /Users/Shared/sv-mike/worktrees (more on that later).

This lets me have somewhere safe that’s readable and writable to both users.<br>Note, you’ll need to add to your ~/.gitconfig for both to not freak out git with the group writable permissions:

[safe]<br># It's expected that sandvault directories are owned by another user.<br>directory = /Users/Shared/sv-mike/repositories/*

🌳 Worktrees

Once I had Sandvault working nicely with Claude and Codex I could be a lot more productive with just letting...