DEV Community

Karim Masmoudi

Posted on Oct 10

I run Claude Code with permission prompts off, so I put it in a VM

#claudecode #macos #security #opensource

I use Claude Code every day, and I run it with permission prompts off. It's much faster that way. You give it a task, go do something else, and come back to a finished change.

The downside is finding out afterwards what else it did. Git can bring back tracked files, but not untracked or ignored ones, and not anything outside the repo.

Most agent sandboxes I tried mount the project folder into a container or VM read-write. That stops the agent from touching the rest of my Mac, but its changes still land in my real files as it works. By the time I look, they're already there.

So I built Mudroom, a free and open source Mac app and CLI that keeps the agent off the real folder completely.

How it works

Mudroom makes an APFS copy-on-write clone of the whole project folder, untracked and ignored files included. The clone takes no extra disk until files change.
It boots a Linux micro-VM with Apple's container tool and mounts only the clone. Your real folder is never mounted.
Claude Code, Codex, Gemini CLI, opencode, Aider or any command runs inside, in a normal Terminal window, so you can still talk to the agent.
When the agent exits, you get a diff that looks like a pull request: added, modified, deleted and permission changes, file by file. Modified files have a checkbox per hunk.
You apply everything, some files, or single hunks. Every apply can be undone. If you edited a file yourself while the agent was running, it's flagged and never overwritten.

The same thing from the command line:

mudroom run ~/code/myapp -- claude --dangerously-skip-permissions
mudroom diff last
mudroom apply last --all
mudroom undo last

The network part

By default the VM sits on a host-only network with no DNS and no route out. The only way out is a logging proxy that lets through the agent's own API hosts (for Claude Code that's api.anthropic.com and a few sign-in hosts) plus anything you add.

The review screen has a Network tab that lists every host the VM tried to reach, blocked ones first. If something legitimate got blocked, one click adds it to the project's allowlist for the next run. mudroom network check tries to get around the proxy from inside the VM and prints what it could and couldn't reach.

Signing in once

mudroom agent login claude (or "Use my Claude account" in the app) runs claude setup-token and stores the token in the macOS Keychain, so later sessions start signed in. Your real ~/.claude is never mounted. ANTHROPIC_API_KEY works too.

What it doesn't do yet

I'd rather list these up front:

The app and the VM need macOS 26 or later on Apple silicon. Linux and Intel Macs get a CLI-only build on Docker or Podman, which is a container, not a VM.
The VM can reach services on your Mac that listen on 0.0.0.0. The network check reports it. I don't have a fix yet.
While a session runs, Apple's container runtime keeps the session environment, tokens included, in a config file that any process running as you can read.
The allowlist works on host names. There's no TLS inspection.
The app isn't notarized. The install script and Homebrew cask clear the quarantine flag.
Lockfiles and generated files make noisy diffs. It's early.

If your project is a git repo and you're happy reviewing with git, Docker Sandboxes' clone mode gets you close. Mudroom also covers untracked and ignored files, folders that aren't repos, and gives you a review screen and an undo for each apply.

Try it

brew install --cask kernel-hunter/tap/mudroom

or the one-line install script in the README. There's also a 33-second overview video with sound.

It's MIT licensed and free. I'd like to hear from people who run agents unattended:

Is the end of the run the right time to review, or would you want checkpoints in the middle?
How should generated files and lockfiles show up in the diff?
Which agents or setups should I test next?

Kernel-Hunter / mudroom

Run coding agents in a Linux VM on a clone of your project, then review and apply their changes like a pull request

Mudroom

Run coding agents in a sandbox, then review their changes like a pull request before anything touches your project.

Coding agents work best with permission prompts turned off, and that means they can delete files or reach any host while you aren't looking. Mudroom runs Claude Code, Codex, Gemini CLI, opencode, Aider (or any command) in a Linux micro-VM, on a copy-on-write clone of your project, with network access limited to the hosts you allow. Your real folder is never mounted. When the agent is done you read the diff, apply all of it, some files, some hunks or none, and undo any apply later.

macOS app and CLI on Apple-silicon Macs. CLI only (with Docker or Podman) on Linux and Intel Macs.