The problem, new and old
Coding agents are great right up until you remember what they actually are: a loop that runs shell commands and rewrites files on your behalf. rm, curl | bash, pip install, git clean -fdx, against your real home directory, your real SSH keys, your real .env. One confidently wrong step, one prompt-injected README, one hallucinated path, and the blast radius is your whole machine.
It's the same shape as an older problem every developer already has: "let me just try this repo."
That repo installed a global CLI. That tutorial needed Python 3.10 when you had 3.12. That quick test edited your PATH. Individually harmless; collectively, the reason "works on my machine" is a meme.
Both problems have the same fix: don't let untrusted work touch your host. Run it in a box you can throw away.
Why not the existing answers
- Cloud agent sandboxes (E2B, Modal, Northflank): excellent isolation, but metered, account-gated, and your code runs on someone else's infrastructure.
- Cloud IDEs (Codespaces, Gitpod): same "your code lives elsewhere, on a meter" trade.
- Devcontainers: great if the repo ships the config and you live in VS Code. An agent's scratch box ships nothing.
-
Raw
docker run: works, but now you're the flag manager, volume janitor, and port accountant, and there's no UI to see which env each agent is thrashing.
I wanted the local, free, private version: the code never leaves my machine, no account, no bill.
The tool
miniVE is a small open-source desktop app (Tauri: Rust + Svelte) that wraps the docker-as-throwaway-box workflow in a UI, and it happens to be exactly what you want to hand an agent.
Create. Name it, pick Python 3.10/3.11/3.12, Node 18/20/22, or blank Ubuntu 24.04, optionally map ports. It creates one container plus one persistent volume mounted at /workspace.
Point your agent at it. Open a shell into the environment and run your agent's CLI inside the box, or clone the repo in and let the agent loose. It can install whatever, run whatever, delete whatever, inside /workspace. Your host filesystem, keys, and credentials aren't mounted, so they aren't reachable.
Work. Multi-tab interactive terminals (a real TTY: colors, Ctrl-C, TUI apps work). Upload files or paste a git URL to clone inside the environment. pip install / npm install persist across stop/start, so an agent's setup survives a restart.
Preview. Run a dev server bound to 0.0.0.0 and the mapped port renders in a preview pane (or your browser at localhost). Check what the agent built without leaving the app.
Delete. The container and its volume are removed together. docker ps -a | grep minive returns nothing. Whatever the agent did, it's gone. That guarantee is the entire point.
CLI. A minive binary ships alongside the app: create, list, shell into, and delete the same environments from your terminal. GUI and CLI see the same state, so scripting an agent harness against it is trivial.
The honest part about the threat model
This is container isolation, not a microVM. It reliably stops the realistic failure ("my agent nuked my home dir," "a repo's install script leaked my .env"). It is not a guarantee against a determined kernel escape by genuinely hostile code. For running your own agents against your own code on your own machine, container-grade isolation is the right trade; if you're detonating actual malware, reach for gVisor or Firecracker.
There's no other magic. Every environment is one container plus one volume with a minive.env label; audit it with plain docker commands. No account, no telemetry, no server.
Try it
Free, MIT, Windows/macOS/Linux. Requires Docker Desktop (Docker Engine is enough on Linux).
Repo: https://github.com/SahilSidhu7/miniVE
If you try it, I want the bug reports and the feature complaints, especially: what would it take to make this your default box for both agents and random repos?
Top comments (0)