Sandboxes and worktrees: Isolating AI agents without losing productivity

Granting an AI agent access to your file system and development environment is a decision many make without much thought to the consequences. Mike McQuaid, known primarily for his work on Homebrew, published a detailed post this week on how he structured his workflow in 2026 so that agents can operate with real autonomy without compromising system integrity. The thread on Hacker News hasn't generated much discussion yet, but the article deserves attention for its concrete, reproducible approach.

The premise is straightforward: if an agent can read, write, and execute code on your machine, it can also break things, leak secrets, or introduce unwanted changes to the wrong branches. Almost no one disputes this in theory, but few publish actual configurations that solve it without sacrificing the fluidity of daily work.

Git worktrees as an isolation unit

The technical core of the proposal is the use of git worktrees: a native Git feature that allows multiple working copies of the same repository in separate directories, each pointing to a different branch. This isn't new, but McQuaid applies it systematically so that each agent session operates in its own worktree, completely separate from the main working directory.

The immediate advantage is that an agent modifying files, installing dependencies, or running scripts does so in isolated space. If something goes wrong, the main directory stays intact. Merging, if appropriate, becomes an explicit human decision.

This approach aligns well with the workflow model of Claude Code, Anthropic's official CLI, which already supports specialized sub-agents and hooks in lifecycle events (PreToolUse, PostToolUse, Stop). Launching a sub-agent pointing to a specific worktree is, in practice, delegating a bounded task to a disposable environment.

Sandboxes for system access

Beyond Git, McQuaid adds an operating system-level sandboxing layer to restrict what the agent process can do: network access, permitted file paths, exposed environment variables. On macOS, he mentions using sandboxing tools available in the system; on Linux, the equivalent would be namespaces or lightweight containers.

This level of control is relevant because modern agents, including those running Claude Opus 4.7 or Sonnet 4.6, can invoke external tools via MCP servers configured in `claude_desktop_config.json`. If an MCP server has access to credentials, databases, or production APIs, the blast radius of a mistake or a poorly formulated instruction can be substantial. Limiting that access from the operating system is an additional safety net that doesn't depend on the model making good decisions.

Why this kind of documentation matters

The most valuable aspect of the article isn't any particular technique, but rather that someone with real experience in developer tools takes the time to document a complete, functional workflow. Most guides on AI agents stick to lab demonstrations. A configuration someone uses daily in real projects is far more useful as a reference.

This type of setup is particularly relevant for:

• Solo developers who want to delegate refactoring or test generation tasks to an agent without risking their main branch.
• Small teams beginning to introduce Claude Code into their workflow without formal security policies yet.
• Open source project maintainers where agents can propose changes requiring human review before integration.

The worktrees plus sandbox approach is also compatible with Claude Code hooks: you can configure a PostToolUse hook that cleans up the worktree automatically after each session, or runs the project's tests before allowing the agent to continue.

Editor's take

That in 2026 it's still newsworthy for someone to document how to use agents in a minimally safe way says quite a bit about the operational maturity of the ecosystem. McQuaid's technique isn't complex, but the fact it isn't already encoded as standard practice in Claude Code's official documentation is a debt Anthropic should settle soon.