Let AI agents build freely.
Never let them touch your Mac.
isolator runs coding agents — Claude Code today — inside throwaway Docker sandboxes with no host bind mount, default-deny network egress, and a tamper-evident audit trail. Every build, lint, and test runs for real, gated by keel — inside a box that structurally cannot reach the rest of your machine.
The problem
An agent that can build your project can also read your Keychain.
Coding agents are useful precisely because they run shell commands, write files, and reach the network without asking permission for every step. That's also exactly the access profile of something you don't want running unconstrained on the machine that holds your SSH keys, your other repos, and your browser sessions.
Most "sandboxing" is a shell script and good intentions. isolator makes the boundary structural: no bind mount to any host path, no Docker socket, a network that has no route out except through an explicit allow-list — verified against a live container every time, not assumed from the config file.
What it actually does
Every control here is checked, not claimed
isolator selftest asserts every one of these against a running
container — a future change that weakens one is caught immediately,
not discovered during an incident.
No host bind mount, ever
Project code lives only in a Docker-managed volume. The container has
no path into your Mac's filesystem — reachable only via isolator
shell or a real git push.
Default-deny egress
An internal network with no internet route of its own, plus a forward-proxy sidecar that allow-lists by hostname. Everything else gets a 403, logged.
Tamper-evident audit chain
Every command, egress verdict, and git push is appended to a
SHA-256 hash chain. --verify catches an edited, deleted, or
reordered entry — proven with a live tamper test, not just a unit test.
Active breakout battery
Beyond static config checks, selftest actually tries a
canary-domain connection, a write to the read-only rootfs, and a
docker.sock probe — and expects every one to fail.
Gated delivery via keel
Spec → plan → build → gate → merge, with a runnable oracle behind every acceptance criterion. Real build/test/lint commands, executed inside the sandbox, not simulated.
Keychain-sourced secrets
isolator secrets set my-app ANTHROPIC_API_KEY once — every
future isolator up just works. Redacted from the audit chain
automatically, wherever it was resolved from.
No docker.sock, never
A sandbox with the Docker socket can control every other container on the machine. Treated as equivalent to host root, and never granted — checked, not just documented.
Real GitHub workflow
isolator new --github creates the repo, clones with a
credential helper that never puts the token in ps output, and
ships with a real git push through the egress gateway.
Evidence export
isolator audit --export bundles the audit chain plus keel's
own evidence trail into one tar.gz — a reviewable record of
exactly what happened, and when.
Migrate what you already have
isolator import my-app --from ~/Repos/my-app transfers full
history via a one-shot git bundle — never a bind mount —
and preserves an existing GitHub remote automatically.
Architecture
One shared boundary, not one shared kernel of trust
keel — the gated orchestrator that drives the agent — runs inside the sandbox, because keel itself does no isolation. The isolation is built entirely at the container layer, underneath it.
- the
isolatorCLI - ~/.isolator/ audit trail
- your other repos, Keychain
- keel + agent CLI + toolchain
- workspace = named volume only
- non-root, read-only rootfs
- default-deny forward proxy
- allow-list by hostname
- every request logged
The sandbox is attached only to an internal: true network —
Docker gives it no route to the internet at all. Its only path out
is through the egress gateway, which is attached to both that
internal network and the real one. No bypass route exists, not even
by ignoring HTTP_PROXY.
Who this is for
Give an agent real access, on purpose, inside a box you trust
Running Claude Code against a repo you haven't fully vetted
A cloned repo's .keel/keel.toml, or the agent's own output, is
untrusted input the moment it exists. isolator makes the blast
radius one throwaway container, never the machine underneath it.
A one-Mac fleet of AI-assisted projects
isolator new/up/down/shell makes spinning up a new
isolated project as easy as the one it replaces — ideation to
shipped, without hand-rolling Docker Compose each time.
Proving what an agent actually did
A hash-chained, exportable audit trail — every command, every egress verdict, every push — for teams that need evidence an agent's work is trustworthy, not just a claim that it is.
Security-conscious solo builders
Let an agent run npm install, hit real registries, and push to
GitHub — freely, inside a sandbox that structurally cannot reach
your SSH keys, your other repos, or anything else on the host.
Proof, not vibes
Every claim on this page was tested against a real container
- e2e tests/e2e.sh live-tampers with a real project's audit chain file and confirms
--verifycatches it — not a mocked test. - walkthrough A real project run found two genuine keel gate violations (an under-scoped test file, an under-scoped lockfile) and three real isolator bugs — all fixed and documented, not hidden.
- decision record Runtime choice is a sourced ADR, not a guess: gVisor and Apple's native
containertool were both investigated and rejected with cited evidence, including a confirmed open security hole in the alternative.
Quick start