Show HN: Isolade, a local-first coding agent workbench with secretless microVMs

Show HN: Isolade, a local-first coding agent workbench with secretless microVMs(github.com)

3 points by jachris 5 days ago | 4 comments

I built Isolade because I could not find an open-source, local-first workbench that runs coding agents in microVMs.

The two pieces already exist individually. There are plenty of options for both agent management (Conductor, Herdr, Omnigent) and microVM isolation (Docker Sandboxes, Firecracker, SmolVM). However, I did not find a project that combined them into one unified product.

Isolade gives each agent its own microVM. Microsandbox provides subsecond provisioning and domain-scoped secret substitution, so that the VM only sees placeholder values. Instead of a worktree, each agent gets a copy-on-write clone of the entire setup. This works well for setups involving multiple repositories, and cached dependencies mean agents can start working immediately without any per-worktree setup.

A single UI lets you work with multiple agents concurrently. You can mix Anthropic and OpenAI models and switch providers in the middle of a conversation. For example, I often have Sol review Opus's work. The system prompt is customizable, so for UI tasks, I ask agents to include actual screenshots of their changes or proposals in the conversation. This works much better than Claude's ASCII art.

You can use your existing subscriptions because Isolade runs the official Claude Code and Codex binaries.

Isolade is Apache-2.0 licensed and supports Apple Silicon macOS and Debian or Ubuntu with KVM. Looking forward to hearing your feedback.

fastandfearless 5 days ago |

I can only say the same: "Most people run their coding agents directly on the host system." And the problem between the host system and the microVM approach is the same, only that the host system is not isolated. But in both cases, I want the secrets to be undiscoverable by the AI. I use YubiKeys for SSH auth, so the AI could not use SSH without my consent. But for all other credentials like .files I almost saw the AI figure out how to use them without my consent. So your idea is good, but let's think about a bearer token for an API: how could an API use that without seeing the content of the token? I thought of building a universal token-injector API proxy, but that is very limited; REST might work, WebSocket connections won't work with this, and most API implementations do not allow setting alternative endpoints. And I don't want to think about Mutual TLS. So I decided to build something that tries to get consent for access to .files or passwords from password stores. There is a very early implementation only for SSH agents in github.com/mabels/project-43.

jachris 5 days ago | |

  But in both cases, I want the secrets to be undiscoverable by the AI.

Agreed! But if you use domain-scoped header-only substitution within Isolade, then the AI really has no way to get the actual value (unless the service behind that domain echoes it back to you – but no sane API would do that). It only sees a unique placeholder.

  How could an API use that without seeing the content of the token? I thought of building a universal token-injector API proxy, but that is very limited; REST might work, WebSocket connections won't work with this, and most API implementations do not allow setting alternative endpoints.

You don't need alternative endpoints. The microVM starts with a preloaded CA certificate and network proxy that allows intercepting all HTTPS traffic. Websocket works if the authentication happens as part of the header exchange. Custom protocols would indeed be unsupported, as well as pinned certificates. But so far, I have not come across the need for this.

I have also added support for git commit signing via SSH. The host sets up a tunnel and receives the commit information, signs it, and passes it back to the VM. This also guarantees that the VM has no access to the underlying private keys.

That being said, manual approval could still be useful for certain privileged operations. For example, letting the agent access information of a production system. I agree that some approval mechanism would be useful for that. I think microVMs make for a perfect separation here, such that host can decide on a case-by-case whether to allow a given operation.

BehanPrW 5 days ago |

curious, what is the alternative to running a coding agent in microVM? I'm new to this.

jachris 5 days ago | |

Most people run their coding agents directly on the host system. In my opinion, this is not a good long-term solution. Regular usage requires some kind of isolation, unless you like living on the edge. Codex ships with a lightweight sandbox, which most of the time just gets in the way by requesting manual approval. Claude has Auto mode, which tends to work a bit better in my experience, but doesn't really protect your host in the same way a sandbox does. So, you either need a full container for your whole setup, or a microVM. The latter provides stronger protection guarantees, but is a bit more heavyweight than a container. Microsandbox microVMs start super fast though, and so far I have not had an issue with resource consumption. It also has the advantage that agents can use Docker without the usual Docker-in-Docker problems. All in all, I think microVMs are the best approach here, potentially with containers nested inside them if resource usage becomes a problem.