Isolated VM environments for cloud coding agents, explained

An autonomous coding agent installs packages, runs arbitrary commands, starts databases, opens browsers and edits files, often with permission prompts turned off so it can work unattended. Where that happens matters more than almost any other choice you make about cloud agents.

The baseline we recommend: one isolated virtual machine per task, configured once by your team and booted fresh every time.

Why a VM per task

Nothing leaks between runs. Two agents working on different tickets never see each other's files, processes, environment variables or half-installed dependencies. A failed run can't poison the next one.

The agent can verify its own work. With a whole machine it can install your toolchain, run Docker and docker-compose, start your services, run the full test suite and click through the UI in a real browser. That's the difference between a pull request that compiles and one that works.

The blast radius is one disposable machine. If an agent runs something it shouldn't, the damage stays inside a VM that's destroyed when the work is done. Credentials are scoped to what that environment was given.

Laptops are out of the loop. The work continues when the engineer closes the lid, and ten tasks can run at once without ten laptops.

VMs, containers and shared machines

Containers are a reasonable middle ground for short, trusted jobs like CI. For agents that run untrusted, model-generated commands and need to run your full stack, a VM is the cleaner boundary.

What a good agent environment includes

The VM is only useful if it's ready to work in. Look for:

• Repositories cloned, including several repos and, if you need it, both GitHub and GitLab in one workspace.
• Dependencies preinstalled through setup or warm hooks and snapshots, so each task doesn't spend ten minutes on npm install.
• Secrets injected safely, encrypted at rest, ideally synced from a manager such as Doppler or Infisical, and lockable by admins.
• Tools the agent can use: MCP servers, skills and instructions configured once for the whole team.
• A desktop and browser so the agent can test the UI and hand back screenshots and recordings.
• Right-sized machines: small for quick fixes, larger for builds and test suites.
• Network controls for what the agent can reach.

How the main options compare

Most hosted coding agents now run tasks in a VM:

• Replicas gives each workspace its own Linux VM (2, 4 or 8 vCPU with 8, 16 or 32 GB), configured once per team environment with warm hooks, MCP servers, skills, files and secrets, plus a desktop with Chrome. It runs Claude Code, Codex, Cursor, OpenCode, Pi or Muse Code inside.
• Devin boots a fresh copy of your organization's snapshot in a Linux VM per session, built from a blueprint it proposes for each repository.
• Cursor Cloud Agents run in isolated VMs set up by an agent, a saved snapshot or a Dockerfile, with secrets, outbound domain restrictions and remote desktop control.
• Claude Code on the web and Codex cloud run sessions in their vendors' VMs, with network access set per environment.
• OpenCode runs wherever you put it; isolation is yours to build.

The differences are less about "VM or not" and more about setup effort, how much of your stack fits, which agents can run inside, and who controls the configuration.

Questions to ask a vendor

• Is every task a fresh VM, or do tasks share a long-lived machine?
• What happens to the machine and its data when the task ends or the workspace sleeps?
• Can admins define the environment once and lock it, so engineers can't widen access by accident?
• Can I turn off retention of chat history after a run?
• Can it run in my own cloud if security requires it?

If isolation is a hard requirement, say so in the chooser: it becomes a must-have, and anything that can't meet it drops down the ranking.