███████╗██╗██╗      ██████╗
██╔════╝██║██║     ██╔═══██╗
███████╗██║██║     ██║   ██║
╚════██║██║██║     ██║   ██║
███████║██║███████╗╚██████╔╝
╚══════╝╚═╝╚══════╝ ╚═════╝

Silo is a CLI tool that runs AI coding agents in isolated containers and lightweight VMs so they get full access without touching your machine.

# Install with Homebrew
brew install --HEAD leighmcculloch/silo/silo

# Or install with Go
go install github.com/leighmcculloch/silo@latest

# Run
silo

My problem

AI coding agents need broad access to be useful. They read files, run commands, and modify code. When we restrict them with permission prompts we put ourselves back in the loop – approving, reviewing, approving – and lose the thing that makes them useful. To really leverage them we need them unblocked.

The tools have options for this. Claude Code calls it yolo mode. But giving an agent full access to your machine is a real tradeoff. I learned this the hard way when a permitted gh api call caused an agent to comment on a random GitHub discussion completely unrelated to my work.

What I’ve tried so far

Permissions. I tried configuring detailed permission lists – allowing specific commands like git, gh, cargo, go, npm, and specific read/write paths. It felt thorough but it wasn’t. The surface area is too large and one permitted command can do unexpected things.

Sandboxing. OpenAI Codex CLI shipped sandbox mode first, then Claude Code added it. I experimented with macOS sandbox-exec and custom rules. Hard to get right – build caching broke, Go build cache errors, flaky tool behavior. If you’re not using any isolation right now, turn on sandboxing in Claude Code. It’s the best place to start, good safety with minimal effort. But I wanted more.

Remote agents. Claude web, GitHub Copilot coding agent – run the agent on someone else’s infrastructure. Great for long-running investigative tasks, good for hands off spikes, but the machines aren’t ours, they lack our local tools, and they’re often limited.

Containers and VMs. Real isolation. The agent gets full access inside a throwaway environment. No permission lists, no fragile sandbox rules. I tried shell scripts wrapping Docker, VS Code Dev Containers, Lima, and UTM. They all worked to varying degrees but none were seamless enough for daily use.

And then there was Silo

Silo was born from wanting a single command that gives AI agents full capability inside isolation. The agent runs in yolo mode with everything it needs – but only inside a container with access to the working directory.

silo claude

That’s it. Silo builds the environment automatically on first run.

Features

Two isolation backends

Silo supports two backends and auto-detects which one to use:

Docker works on any platform. All containers share one Linux VM and the shared kernel. Good default, works everywhere.

Apple Container is macOS only. Each container runs in its own lightweight VM with its own kernel. Stronger isolation since each VM has its own resource constraints and no shared filesystem access beyond what’s explicitly configured. Silo uses this backend automatically if the container command is installed.

Built-in

The container comes with a pre-built dev environment:

  • Base: Ubuntu 24.04, build-essential, pkg-config
  • Languages: Node.js, Go, Rust (latest stable)
  • Tools: git, GitHub CLI, Docker CE, jq, zsh
  • LSP: gopls, rust-analyzer
  • MCP Servers: github-mcp-server pre-installed

Git identity is auto-configured from the host. Filesystem paths mirror the host layout so tools behave the same way inside and outside the container.

Seamless local and silo workflow

Tool config directories like ~/.claude are mounted from the host. This means you can start a session in silo, then continue it locally:

silo claude              # agent works on stuff unattended
claude --continue        # continue same session locally

Continuing locally gives you full access to API keys, GitHub tokens, and everything else on your machine when you need it.

Configuration

Silo uses a hierarchical config system with JSONC files that merge together:

silo config init         # create a starter config
silo config show         # show merged config with source annotations
silo config edit         # edit in your $EDITOR

Configuration is loaded in order: built-in defaults, then ~/.config/silo/silo.jsonc, then ./silo.jsonc files from the filesystem root to the current directory. Arrays append, scalars override.

Repository-specific configuration can be applied automatically based on git remote URLs:

{
  "repos": {
    "github.com/myorg": {
      "env": ["ORG_API_KEY"],
      "post_build_hooks": ["npm install -g @myorg/cli"]
    }
  }
}

Everyone should be isolating

There’s a whole spectrum of approaches to this problem – permission lists, sandbox modes, remote agents, Docker containers, VMs. Silo sits on the container and VM end of that spectrum, optimized for getting out of the way while keeping your machine safe.

Give it a go

# Install with Homebrew
brew install --HEAD leighmcculloch/silo/silo

# Or install with Go
go install github.com/leighmcculloch/silo@latest

# Run
silo