Turn the permission prompts off. Keep the boundary on.

What it is

Two jobs, one command

~/.sandy/sandboxes/
├── webapp-a1b2c3d4/       # one sandbox per project, named from its path
│   ├── claude/            # mounted at ~/.claude: plugins, memory, history
│   ├── codex/             # and one home per agent you use there
│   ├── pip/  npm-global/  go/  cargo/  uv/   # packages you install persist
│   └── WORKSPACE.json
└── data-pipeline-e5f6a7b8/
    └── claude/            # a different project, a different agent home

The problem

An agent on your laptop runs as you

It reads files it did not write, and any of them can carry instructions. Give it autonomy and it acts on them with your user's full reach. Three kinds of reach matter.

The problem

A permission prompt is not a boundary

Asking before every command protects you only if you read every command. After the fortieth prompt nobody does. sandy moves the decision out of the agent and into the operating system.

The layers

Six layers, each enforced below the agent

The layers · network

Three network postures, one setting

The proxy works the same on macOS and Linux because the isolation comes from Docker's network layout, not from firewall rules on the host. Most people never change the default.

The proxy reads the hostname from the TLS handshake and never decrypts. It logs what it refused, and with SANDY_EGRESS_LOG=1 every distinct host the session reached, so after a suspicious session you can answer "what did it talk to?"

The seam

The boundary is a mount table

This is everything the agent can see of your machine. Anything not in the table is not mounted at all, so there is nothing for the agent to read, however it asks.

Trust tiers

A repository can tighten the sandbox, never loosen it

A project can commit a .sandy/config so everyone who clones it gets the same setup. Clone someone else's repository and that file is theirs, so sandy treats it accordingly. It is read as KEY=VALUE lines and never run as a script.

Settings in your own ~/.sandy/config never ask: that file is yours. Approval is per workspace and remembered, and any change to the approved keys asks again.

Trust tiers

Three approval gates, all before the container starts

When nobody can answer (a one-shot sandy -p, a background start with no terminal), every gate fails closed. sandy --approvals reports what each gate would decide for a workspace without granting anything.

Knowing it holds

You can check, from inside and out

Knowing it holds

What sandy does not do

A sandbox you can trust is one whose limits are written down. These are the main ones; the threat model has the rest.

• Your code is writableThe agent edits your project, which is the point. Commit before a session and review the diff after it.
• Some paths are detect, not preventA protected path is locked only if it exists at launch. One the agent creates is reported at session end, before your next git or IDE action would use it.
• macOS with the proxy offSANDY_EGRESS=off on macOS leaves the LAN reachable. Keep the default proxy on.
• A container, not a VMOn Linux the agent shares the host kernel. On macOS, Docker itself runs in a VM.
• Credentials it is givenA login token is usable for its lifetime. For a repository you distrust, SANDY_SUSPICIOUS=1 strips the refresh token and defaults to strict egress.

Knowing it holds

How it compares

Other good tools attack the same problem from different angles. Each picks a different trade, as of October 2026.

Choose a microVM for a hypervisor boundary, Windows, or Docker inside the sandbox. Choose sandy for your existing Docker, repos you didn't write, several agents, and separate per-project setups. The README's Why sandy section has the full comparison and its sources.

Many agents

Five agents, alone or side by side

Every agent gets the same boundary and its own home directory and credentials inside the project's sandbox. Pick one per project, or run up to four at once.

SANDY_AGENT=claude,codex      # two panes, side by side
SANDY_AGENT=all               # claude, gemini, codex, opencode

Run it · 1 of 4

Check your machine

curl -fsSL https://raw.githubusercontent.com/rappdw/sandy/main/doctor.sh | bash

The doctor checks that Docker is reachable, that git and curl are present, that your agent credentials can be found and that ~/.local/bin is on your PATH. For anything missing it prints a command to copy.

Run it · 2 of 4

Install, then launch in a project

curl -fsSL https://raw.githubusercontent.com/rappdw/sandy/main/install.sh | bash

cd ~/dev/myapp
sandy                          # interactive session
sandy -p "summarise src/"      # or a one-shot prompt

The installer puts one script in ~/.local/bin. The first launch builds the images, which takes a while once; after that, sessions start in seconds and the images rebuild themselves when your agent releases an update. Claude Pro and Max logins are picked up from your host, so there is no API key to set.

Run it · 3 of 4

Make it yours

SANDY_AGENT=claude
SANDY_EFFORT=high
SANDY_EGRESS=strict        # tighter than the default
SANDY_MEM=8g

Precedence runs from a command-line flag, to your shell environment, to the project file, to your own defaults.

Run it · 4 of 4

Keep sessions running, and keep the host tidy

sandy --start     # start detached; survives a closed terminal or a reboot
sandy --attach    # attach from any terminal or over ssh
sandy --stop      # tear it down

sandy --doctor            # host and runtime health
sandy --gc --dry-run      # show unused images and networks
sandy --reset-sandbox     # rebuild a sandbox you no longer trust
sandy --upgrade           # update sandy itself

Daemon mode is what sandy-ui uses to keep a session alive across VS Code restarts. Every maintenance command prints its plan first, and --dry-run stops there.

sandy

Let the agent work. Let the kernel say no.

sandy is one MIT-licensed bash script. It runs on any Docker-compatible runtime on macOS or Linux and needs no server or account of its own.