TL;DR
- Trail of Bits’ coop runs Claude Code and Codex in disposable VMs, using Firecracker on Linux and Lima on macOS.
- Templates, project copy/sync, live sharing on macOS and model-service connections support the development workflow.
- Start with a non-sensitive repository and test the complete loop: launch, work, review and bring changes back.
- Shared files, supplied credentials and permitted network connections remain accessible according to the configuration.
In plain English
A virtual machine, or VM, runs a separate operating system on your computer. Your everyday computer is the host; the environment inside the VM is the guest.
A template supplies the starting environment for new instances, including the tools and configuration they need.
A live mount makes files available across the host/guest boundary, with changes visible on both sides. Sync transfers copies at particular points in the workflow.
A credential proxy handles selected authenticated requests so the guest can use a service without holding its underlying API key.
Trail of Bits’ coop runs Claude Code and Codex inside disposable virtual machines. Each agent gets a separate operating system and development environment where it can install packages, compile code and use its tools, with a defined connection back to the project on your computer.
That is useful for a familiar part of agent-assisted development. Giving an agent a task often also means letting it change its environment: install a dependency, run a setup script or modify configuration. A separate working environment gives those operations somewhere to happen without making your everyday computer the immediate target of every command.
coop uses Firecracker on Linux and Lima on macOS. You prepare a template with coop setup, start a project environment with coop up, then launch the agent through coop claude or coop codex. The guest contains the tools the work needs and can be replaced when you no longer need that environment.
The project still has to get into the guest, and the workspace documentation explains the choices. The normal copy mode transfers the project into the VM. coop push and coop pull handle later transfers, so you can bring work back to the host. There is also an option to clone a Git repository directly inside the guest.
For people who want to keep working on the host’s files, the mount option behaves differently by platform. On macOS, Lima provides live filesystem sharing: changes are visible on both sides. On Linux, Firecracker performs a one-time sync for this option, with push and pull available for later changes. That difference matters when deciding where to edit and how to collect the result.
The design also accommodates model access. The trust model describes connections for a local-model gateway and an optional credential proxy. The proxy handles selected provider requests on the host, keeping the underlying model API keys out of the guest. This lets a guest use those model services without needing those particular keys itself.
These connections are part of making the environment usable. They also define what the VM can reach. A copied project remains available to the agent, a writable live mount can change the host’s files, and a secret included in a workspace is still a secret the guest can read. Guest-to-host networking is deliberately supported for services such as the gateway and proxy. Treat those as explicit choices when setting up a project.
There is a maintenance trade-off too: a separate environment has its own toolchain and template to keep current. The README describes instances as cheap to create and destroy; how that fits a particular project still depends on its dependencies and workflow. This account describes the documented design, without claiming hands-on performance measurements.
I would start with a non-sensitive repository and one ordinary development task. Check that the required tools work, see which files are shared, and walk through bringing the changes back. That gives you a concrete way to judge whether the extra environment helps your work.
coop makes a repeatable development environment part of running an agent. For someone using coding agents on a computer that also holds everyday or client work, it provides a practical way to separate those activities while retaining the project and model connections the agent needs.