coop Runs Codex and Claude Code in VMs

coop is Trail of Bits' open-source Rust CLI for running Claude Code, Anthropic's coding agent, and OpenAI Codex, OpenAI's coding agent, inside disposable virtual machines. It deals with the awkward part of agentic coding: the agent needs Docker, git, compilers, and package managers, but your laptop also has private repos, tokens, browser state, and personal files. The useful takeaway is simple: put the Codex CLI workflow behind a machine boundary first, then keep repo instructions, MCP access, and verification loops small. coop is interesting because it lets the agent have more tools while trusting your host machine less.

What coop actually runs

coop manages short-lived VM environments for coding agents. A disposable agent VM is a throwaway machine where the agent can edit code, install dependencies, run builds, and break things without getting broad access to the developer's host filesystem. Devin Workshop is part of Harness Institute.

The project is small and concrete. As of September 2026, the repository has 32 GitHub stars, is mainly Rust, uses the Apache-2.0 license, and was last pushed on September 4, 2026. The README describes the point plainly: Claude Code and Codex get full tool access inside isolated, reproducible VMs that are cheap to create and destroy.

The backend matters. On Linux, coop setup installs Firecracker and fetches a guest kernel. On macOS, coop expects Lima to be installed first, commonly with Homebrew. The project says it is tested on macOS arm64 and Linux x86_64, while Linux arm64 builds exist but are untested.

That is enough to explain why developers noticed it. The pain is not that Codex cannot run commands. The pain is that giving an agent useful command access on your real workstation feels like handing a junior engineer your whole laptop and saying, please be careful.

Why the VM boundary got attention

The clean idea in coop is not a new prompt trick. It is a boring boundary, which is usually the good kind.

A coding agent often needs to run exactly the commands you run: install packages, compile native modules, launch Docker services, inspect test failures, and patch files. If the only safe mode is read-only chat, the work stalls. If the agent can mutate your whole home directory, the work feels spooky.

coop splits that difference. The agent gets a real development environment, but that environment is not your host. For Codex CLI users, that means a Codex agent can do real repo work while your other projects, SSH material, dotfiles, downloads, and local app state are not casually in scope.

The trap is treating VM isolation as perfect security. It is not. A VM boundary is much stronger than a prompt boundary, but it is still software, it still depends on host configuration, and it does not automatically solve secrets, network access, or connected tools. Do not mount your whole home directory and then call the result isolated.

What is clever, and what is still rough

The clever part is that coop aims at the messy middle of agent work. It is not just a container wrapper, and it is not a remote hosted development product. It is a local CLI that creates isolated VM environments where the agent can use ordinary tools.

That fits a real repo workflow better than a toy sandbox. A backend service repo may need Postgres, Docker Compose, generated clients, a native compiler, and a test database. A frontend repo may need Node, browser tooling, and a local build cache. The agent is more useful when it can touch those things inside a machine you are willing to delete.

The rough parts are the same ones you would expect from a young systems tool. Host prerequisites matter. Backend support differs across macOS and Linux. You should expect setup friction around virtualization, kernels, workspace sync, and image profiles before this feels invisible.

There is also a permissions trap around MCP, the Model Context Protocol. If you connect a powerful MCP server with write access to GitHub, Slack, Jira, private docs, or production databases, the VM boundary no longer describes the full blast radius. The agent may be inside a coop VM, but the connected service can still do real work outside it.

This is the same shape of question we saw in fast-cutvid Cuts Video for Agents: once agents can operate tools, the interesting design work moves from prompts to boundaries, receipts, and reviewable outputs.

Try it on one small Codex repo

The safest first experiment is a repo you understand and can reset quickly. Pick a small library, internal tool, or demo service with a real test command. Avoid the monorepo, the production deploy repo, and anything that requires broad personal credentials.

Start with the repo instructions. Codex reads AGENTS.md for project guidance, so make that file describe the boundary in operational terms, not vibes.

# AGENTS.md

## Agent boundary
- Work only inside this repository.
- Do not read, write, or inspect parent directories.
- Do not create commits unless asked.
- Do not add new network services or MCP servers during this task.

## Verification
- Run npm test before handing back changes.
- If tests fail, report the failing command and the smallest suspected cause.
- Include git diff --stat and the files changed in the final note.

Then keep the command loop small. The exact coop launch command may change as the project evolves, so use the repository's command reference for your platform. The important workflow is the same:

# Host setup, from the coop docs
coop setup
coop update

# Inside the disposable project VM
codex
npm test
git diff --stat
git diff

Give Codex one bounded task: fix a failing test, update one dependency, or add one small parser case. Do not start with, refactor the service. The goal is to learn what coop exposes, how workspace sync behaves, how fast the VM feels, and whether the verification loop is easy to review.

If your Codex workflows already use MCP, make the first MCP server read-only. A good first note is: GitHub search is allowed, issue writes are not; package registry lookup is allowed, publishing is not; document search is allowed, document mutation is not. That keeps the experiment about the VM boundary instead of accidentally testing every external integration at once.

For more Codex CLI examples, keep this next to the related training topic, especially if you are comparing local CLI work, AGENTS.md instructions, and verification receipts.

Try coop safely: a small experiment checklist

Use this as the note you paste into the repo issue before the first run.

A useful first handoff from the agent should be boring. It should say what changed, which command passed or failed, and what files were touched. If you cannot review the result without replaying the whole conversation, the workflow is not tight enough yet.

Common questions

Is coop a replacement for Codex sandboxing?

No, coop is a VM boundary around the environment where Codex runs, not a complete security model for every connected tool. It helps keep host files out of scope, but it does not automatically constrain network access, secrets passed into the VM, or write-capable MCP servers connected to the agent.

Does coop work on macOS?

Yes, coop is tested on macOS arm64, including Apple Silicon, but it depends on Lima being installed first. The README says setup fails without Lima on macOS, while Linux setup uses Firecracker and a guest kernel. Check backend prerequisites before blaming the agent.

Can the agent still reach secrets or other projects?

Yes, if you expose them. coop reduces host exposure by running the agent in a disposable VM, but mounted directories, environment variables, copied credentials, and connected MCP tools still matter. The first safe test should sync one repo and avoid broad home-directory mounts or personal tokens.

Is coop only for OpenAI Codex?

No, coop is designed for both Claude Code and Codex. That is part of the appeal: it treats agent CLIs as workloads that need an isolated development machine, rather than designing around one model provider's interface. The repo topics include claude-code, codex, cli, firecracker, lima, and microvm.

Best ways to use this research

• Best for: evaluating whether disposable VM boundaries make your Codex CLI workflow feel safer without reducing the agent to read-only chat.
• Best first artifact: a tiny AGENTS.md file with workspace scope, no parent-directory access, and one test command the agent must run before handoff.
• Best comparison angle: compare prompt-only limits, container-based isolation, and coop's VM approach by looking at what the agent can read, write, install, and connect to.
• Best caution: treat MCP access and secrets as separate boundaries. A VM protects the host filesystem better, but connected services still need explicit limits.

Further reading

• OpenAI Developers — Codex CLI docs
• OpenAI Developers — Codex CLI
• coop — source

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.