microVM isolation
Each agent runs in its own hardware-virtualized VM, so a poisoned dependency or rogue agent stays trapped.
Local-first coding agent workbench
Switch agents like tabs. You sip. They ship.
Isolade runs Claude Code and Codex inside throwaway microVMs on your own machine. They work unattended, with no approval prompts. Each task gets its own isolated VM, so the blast radius never extends beyond it. Agents only ever see placeholders, never your real secrets.
Pour one out
Install in one line.
$ curl -fsSL https://isolade.com/install.sh | shThen open the app and read the five-minute quickstart →
The problem
Agents are most useful when you stop watching them.
A coding agent that asks permission before every command is a slow pair-programmer. One that runs free on your laptop is a liability: it, or a package it just installed, can read your SSH keys, your cloud tokens, and every other repo in your home directory.
Isolade removes the trade-off. Each agent lives in its own microVM with no access to your filesystem or your real secrets. So you can hand it the whole task, walk away, and come back to a diff, not a breach.
How it works
From a profile to a running agent.
Four steps, then you never think about the machinery again.
- 01
Define a profile
Name your repos, point at a Dockerfile, then list the ports to forward and the secrets to expose by name. Isolade takes it from there.
- 02
Build it once
BuildKit runs inside a VM and bakes your repos plus the agent tooling into an image. The layer cache stays warm across builds and across profiles.
- 03
Pour an instance
Each instance is a fresh microVM booted from that image. Spin up as many as you want. Throw them away when the work lands.
- 04
Let agents loose
Claude Code, Codex, or a shell run unattended inside. You watch every agent, steer the ones that drift, and review the diff at the end.
The secretless trick
The agent uses your token. It never sees it.
Inside the VM, every secret is a placeholder. The real value is spliced into outgoing TLS, and only toward the hosts you named.
inside the microVM
agent
$ echo $GH_TOKEN isolade-placeholder-•••••••
The env var holds a worthless stand-in. The real token is never in the VM, the database, or any log.
egress proxy
leaving the machine
→ github.com allowlisted
real token swapped into the HTTP header
→ evil.example not listed
no substitution
The real value only ever reaches the hosts your profile declares. Anywhere else, the request carries nothing but a worthless placeholder — so a rogue agent can't smuggle your token out to its own server.
What's inside
Nine reasons it tastes better.
Secretless
The VM only ever sees a placeholder. The egress proxy swaps in the real token, and only for the hosts you allowlisted.
Run unattended
Inside its sealed VM the agent reads, writes, and runs anything, with no permission prompts to click through.
Local-first
Your source tree stays on disk and runs in local VMs. Model providers only see the prompts and context the agent sends.
Reproducible
Profiles are config-as-code in git. Every teammate spins up the exact same environment.
Multi-repo
One profile spans many repos, so an agent works across the whole project instead of one checkout.
Many agents at once
Watch, steer, and switch between agents in one window instead of juggling a wall of terminals.
Fast rebuilds
A warm BuildKit layer cache, shared Nix stores, and ccache survive across builds and profiles.
Agent-agnostic
Claude Code and Codex today, local models next. No lock-in to a single provider.
Read the label
No magic on the label. Hardware virtualization keeps each agent contained, an egress proxy keeps your secrets out of reach, and it all runs on your own machine, open source top to bottom.
See the architecture → Config as code
Commit the recipe. Everyone pours the same glass.
A profile is one directory you can track in git. It names the repos, the ports to forward, the caches to mount, and the secrets to expose, by name, never by value.
Clone the repo, and your teammate's agents run in an identical environment. No "works on my machine," no shared staging box, no secrets committed anywhere.
Profile reference →# your profiles live in one directory — commit it
$ git init && git add profiles/
$ git commit -m "team dev environment"
$ git remote add origin …:you/isolade-config
$ git push -u origin main
# a teammate clones it and pours the same glass
$ git clone …:you/isolade-config ~/.config/isolade
# secret values stay out of the repo — entered in the UI, never hereStraight answers
The questions people ask first.
Why a microVM and not a container?
Containers share the host kernel. A kernel-level escape or a clever syscall trick gets a malicious process onto your machine. A microVM has its own kernel behind a hardware boundary (Apple's Hypervisor framework or KVM), so the agent is contained by the CPU, not by a ruleset you hope is complete.
Does my code or do my secrets leave my machine?
Your source tree stays on the host and is bundled into local VMs. Agents can still send task context to Claude or Codex as part of normal model calls. Secret values never enter a VM at all. The agent only sees a placeholder, and the real value is substituted into outgoing requests at the proxy, only for the hosts you allowlisted.
What about the OAuth tokens for Claude and Codex?
Isolade signs in itself, in a throwaway VM, and stores its own token under ~/.local/share/isolade at 0600. It doesn't copy your host CLI's credentials, so your claude and codex keep working untouched. The token is mounted only into instance VMs, and the refresh token never leaves the store.
One caveat I should know?
Secret substitution puts the real value into the upstream request. So only allowlist hosts you trust not to echo your Authorization header back somewhere. That's inherent to the design, not a bug, but it's worth saying out loud.
Hand it the whole task. Walk away.
Sealed VMs, secrets the agent can't read, and your code right where it belongs.