Running Claude Code inside a Brig microVM sandbox

I finally stopped letting my autonomous coding agents run directly on my host OS because the risk of an "auto-approve" loop deleting a directory or messing up my local environment is just too high. I've been testing Brig, which is a new open-source microVM sandbox from NOFire AI, and it actually solves the isolation problem for agents like Claude Code without making the setup feel like a massive headache.

How the isolation works

The core idea here is that instead of running the agent in a container or just a shell, Brig spins up a dedicated Linux kernel for the agent. It’s built to work on both Mac (specifically Apple Silicon) and Linux (supporting both x86_64 and ARM).

What I found most useful is how it handles the boundary between your real files and the sandbox. You aren't just dumping the whole machine into a VM; you explicitly choose which project folder and which credentials you want to share. The project directory stays writable so the agent can actually do its job—editing files, running tests, and committing code—but it's trapped within that microVM environment. It also comes with default internet access enabled, which is necessary for most agents to pull dependencies or hit APIs.

Setting up Claude Code in the sandbox

The installation process is straightforward, and the whole stack is under Apache 2.0. The microVMM itself is surprisingly lean, sitting at under 20,000 lines of code, which makes me trust the security model a bit more than some bloated virtualization layers.

Once you have it installed, you don't have to manually configure the VM every time you want to work. You can jump straight into a session using a single command:

brig run claude

This command specifically launches Claude Code inside the isolated environment. I've been using this workflow to let the agent run complex refactors where I've given it permission to execute terminal commands. If the agent hallucinates a rm -rf / or tries to wipe my home directory, it only hits the microVM's kernel and the specific project folder I mapped, leaving my actual macOS or Linux host completely untouched.

Why this matters for my workflow

If you are using tools that have "auto-approval" for terminal execution, you are essentially giving a LLM a loaded gun pointed at your filesystem.

• Security: The agent gets its own kernel, so it can't easily break out to the host.
• Control: You decide exactly which credentials and folders are visible.
• Simplicity: It’s a single command to get a full Claude Code environment running safely.

The architecture is pretty transparent, and since it's open-source, you can actually audit how the mounting and networking are handled. For anyone running high-autonomy agents on their local machine, this is a much tighter way to work than just relying on a standard terminal multiplexer or a basic Docker container.