Moo Versions the Whole Machine

Moo is an alpha open-source project from Evan at Ito, a company building code review that runs code, for giving each Git branch or coding-agent attempt its own isolated Linux machine. Git worktrees isolate files, but databases, ports, packages, services, and .env state still crash into each other. For an ai code review workflow for teams, Don't add more process. “make each agent attempt reproducible enough to review without guessing what happened.”

Moo is a runtime-versioning tool that saves and restores machine state alongside Git commits. As of July 2026, the heyito/moo repository is mainly Rust, MIT licensed, and marked alpha for macOS on Apple Silicon, with Linux hosts planned.

Understand the thing Moo is trying to remove

The problem is familiar if you run several coding agents against one repo.

One agent starts the app on port 3000. Another runs migrations against the same local database. A third changes an environment variable, installs a package, and leaves the machine in a state nobody can reproduce two hours later.

Git worktrees help with source files, but they do not give you a second laptop. Moo’s bet is that the useful unit of isolation is the machine, not just the checkout.

The project describes four verbs: new, run, save, and drop. Each branch, worktree, or agent attempt gets a full Linux microVM with copy-on-write state. When you save, Moo snapshots that runtime state tagged to the current commit; when you check out an old SHA, Moo can restore the matching machine state.

That is why developers paid attention. It attacks the unglamorous part of agentic coding: not prompting, not model routing, but local state collisions.

Don't treat this like a magic sandbox. Moo’s README says it is alpha, macOS Apple Silicon only, and pre-1.0 snapshot formats may change. That is a “try it in a disposable path” signal, not a “move your main development machine over lunch” signal.

Notice the clever boundary: files are not the whole repo

The interesting design move is that Moo does not try to replace Git.

Git still versions code. Moo versions the machine around the code. That separation is clean, and it explains the project’s appeal in one sentence.

A normal workaround looks like this: Git worktrees, a port-offset script, .env symlinks, per-branch database names, and Docker Compose project names. You can make that work, but now every agent task depends on a small pile of local folklore.

Moo compresses that pile into a more memorable mental model: branch equals machine.

For Claude Code this changes the kind of instruction you give the agent. Instead of writing a long prompt about which ports to avoid and which database name to create, you can make the runtime boundary explicit: do the work inside the machine assigned to this attempt, then leave a receipt showing what ran.

A concise repo note can stay boring:

Agent runtime rule:
Use one isolated runtime per branch or agent attempt.
Do not reuse another attempt's database, ports, or background services.
Before review, record the commit, runtime name, migrations run, and test command.

Watch for over-isolating so much that you stop seeing production-like behavior. If every attempt has a pristine universe, you still need a review step that asks whether the change works against real shared assumptions: schema compatibility, external APIs, queues, and deployment config.

Try Moo where parallel agents are actually noisy

Moo makes the most sense when local runtime collisions are the thing slowing you down.

A good example is a Rails, Django, Phoenix, or Node app where every agent needs a database, a dev server, background jobs, and a few ports. If three agents can work at once without stomping on postgres, Redis, or .env, the reviewer gets cleaner diffs and fewer “my machine was weird” explanations.

It is less compelling for a small library with fast unit tests and no services. If the repo is pure TypeScript utilities or a Rust crate with no local database, Git branches plus normal test commands may be enough.

This is also where engineering team ai adoption gets more concrete. The debate stops being “should agents write code?” and becomes “can we isolate attempts well enough that review is about the code, not the mess around it?”

For teams already tightening agent workflows, this pairs naturally with keeping repos small and predictable. I wrote more about that angle in Clean Repos Make Coding Agents Cheaper, because isolation helps most when the repo itself is not a haunted house.

Don't use Moo to hide flaky setup. If your app cannot boot from a clean machine, a microVM will reveal that quickly. That is useful, but it may feel like the tool “broke” things when it actually exposed missing setup documentation.

Put a light review receipt around each agent attempt

The practical move is small: when an agent uses an isolated machine, require a review receipt that names the runtime evidence.

This is the one part that belongs in your agentic coding governance habits. Not a committee. Just a short receipt that lets a reviewer answer, “What code changed, what machine state changed, and what actually ran?”

For Claude Code, a slash-command workflow could be as simple as /agent-attempt-receipt. The command asks the agent to summarize the branch, current commit, runtime name, migrations, services, tests, and known dirty state before opening a pull request.

A useful hook boundary is equally plain: allow agents to create and run isolated environments, but require human confirmation before destructive runtime actions such as dropping a machine or saving a snapshot that should become the review baseline. The exact hook config depends on your repo, but the boundary should be obvious to the developer reading it.

Watch for reviewing the chat instead of the artifact. The receipt should point to commands and state, not narrate the agent’s intentions.

Copyable review checklist for trying Moo safely

Use this checklist for the first few experiments. Keep it next to the pull request, not buried in chat.

For a lightweight ai code review workflow for teams, this checklist is enough to start. Do not add policy until the receipt shows a real recurring gap.

Further reading

• moo on GitHub
• MCP specification
• Claude Code hooks
• Claude Code slash commands