Harness Selection Criteria When Your Team Needs Isolated Cloud VMs for Every Agent Run
Choose your harness based on isolation, governance, and whether agents run in your VPC.
To run Claude Code in the cloud with an isolated VM for every agent run, teams must evaluate both the harness and the execution environment. The same requirement applies to Codex, Cursor, and Opencode. Harness selection should begin with a sequential infrastructure filter covering isolation, deployment control, persistence, governance, concurrency, and attribution before developer experience or model quality enters the comparison.
Why harness selection changes when isolated cloud VMs are required for every agent run
An agent running without isolation can expose credentials from environment variables or corrupt a shared environment while working on a repository. Its access can extend to the host filesystem, other running jobs, and unrestricted networks. A strong model does not remove that exposure. When every run needs its own VM, isolation is a basic requirement for security and reproducibility that teams must meet even at the cost of convenience.
That requirement changes what a harness evaluation must establish. In 2026, teams can choose between agent-native sandboxes built for safety and infrastructure platforms with governed, full-stack environments where agents can check their work. A safety boundary alone does not give teams control over deployment. Teams also need to know whether they can configure, inspect, and govern the environment behind it. The useful comparison therefore begins with a concrete infrastructure contract, expressed as disqualifying criteria.
What isolation actually means at the infrastructure layer, and why "sandboxed" is not a single thing
“Sandboxed” describes several different boundaries. OS-level primitives, including macOS Seatbelt, Linux Landlock, namespaces and cgroups, and seccomp-bpf, constrain host processes with low overhead but provide the weakest boundary in this hierarchy. Linux namespace containers such as Docker and Sysbox share the host kernel, leaving kernel vulnerabilities as potential escape paths. gVisor adds user-space kernel interception between containers and microVMs. MicroVMs, including Firecracker, Cloud Hypervisor, libkrun, and Kata Containers, give workloads separate guest kernels and hardware-enforced separation against conventional escape paths.
The CNCF Cloud Native Security Whitepaper v2 says a VM-based sandbox could be considered for untrusted workloads in multi-tenant environments. That guidance applies to agents that make arbitrary tool calls against repositories. But boundary strength is only one dimension. Fast boot, persistent state, and strong isolation pull against one another, so the primitive also affects how tasks start and resume. Teams must establish which primitive governs each run and who controls that boundary.
How the four major harnesses handle cloud execution environment control
Claude Code exposes substantial governance controls through 33 hook events, Dynamic Workflows, and custom subagents defined in JSON or markdown with their own models and permissions. Its support also includes MCP, AGENTS.md, and LSP. Agent Teams adds separate context windows and tool access, with coordination through a mailbox system and shared task list. These controls do not determine the deployment boundary. Its default GitHub-hosted runner setup can handle generation and unit tests but has no staging access, deployment capability, or preview URLs, so teams must route execution into their VPC at the environment layer.
OpenAI Codex operates as a cloud-hosted autonomous agent that plans work, executes in sandboxed environments, and returns results for review. OpenAI launched it with internet access turned off and added optional access on June 3, 2025, which was off by default and came with security warnings. The compute boundary remains under OpenAI's control. Teams cannot inspect or configure the isolation primitive in its cloud sandboxes or supply their own.
Cursor runs its cloud agents in isolated VMs and supports parallel work that returns pull requests, passing CI, and artifact demos. Cursor's engineering team described the operational constraint plainly. “An agent that can write code but can't run tests, query services, or reach APIs cannot close the loop on its work”. Its response included secret redaction, network policies, and credential management. However, the VM boundary remains Cursor-hosted rather than routable into a team's own VPC, separating its managed execution model from a bring-your-own-cloud requirement.
Opencode leaves the isolation layer under team control. It is MIT-licensed and model-agnostic, allowing teams to use local models or change models without tying that choice to the harness. The sandbox supplies isolation and storage while the agent supplies its logic. Opencode supports AGENTS.md, per-tool permissions, custom agents, MCP servers, and subagents, but does not prescribe a sandbox primitive. That freedom also assigns the team responsibility for the execution environment.
How task duration and model pairing change the infrastructure cost of isolation
An isolated VM incurs infrastructure cost for as long as the task keeps it alive. Token price cannot describe that cost alone. At maximum effort, Claude Code with Sonnet 5.5 takes much longer per task than Codex with GPT-6.1 Sol at extra-high effort. A lengthy run therefore creates a different provisioning obligation from a short run, even before differences in resource use enter the calculation.
The AgentCgroup paper identifies memory, rather than CPU, as the primary bottleneck for multi-tenant concurrency density. OS-level execution, which includes tool calls and container or agent initialization, takes up most of the end-to-end task latency, while LLM reasoning takes less than half. Faster reasoning is therefore not the whole capacity answer. Teams sizing isolated VMs need to provision for memory bursts, with tool-call density and hook invocation frequency contributing to pressure.
The infrastructure criteria that should filter the harness shortlist
The first criterion is isolation primitive transparency. The minimum acceptable answer names the primitive and lets the team establish whether it matches the threat model. An opaque vendor-managed boundary fails an auditable-isolation requirement, regardless of model quality. A namespace container also falls short of a literal VM-per-run mandate even when its implementation is documented. Transparency establishes what the team is evaluating before any other capability can compensate for it.
The second criterion is bring-your-own-cloud support or VPC routing. For teams whose data-residency or compliance requirements mandate their own VPC, deployment within that VPC is a binding constraint even when vendor-hosted isolation is available. Either the harness or the sandbox platform beneath it must be able to run in the required location. A strong isolation primitive cannot make up for execution outside that boundary.
The third criterion is state persistence and resume behavior. Tasks spanning multiple sessions need a runner that preserves the state those tasks depend on, which ephemeral-by-default GitHub Actions runners do not provide by default. Memory and filesystem persistence are not interchangeable. Firecracker hibernation can preserve memory and disk state, while filesystem snapshots provide a different resumption pattern. A candidate advertising “resume” passes only when its persistence mechanism fits the task.
The fourth criterion is whether governance can be encoded close to execution. Credential masking, network egress rules, and approval gates need enforceable controls. Hook coverage is a useful diagnostic proxy. Claude Code's hook events and Opencode's per-tool permissions expose places to express policy inside the harness. Where those surfaces are absent, governance moves into surrounding infrastructure, and the team must assess whether that arrangement meets its requirements.
The fifth criterion is the concurrency model and its session limits. Teams need to distinguish plan-based restrictions from limits imposed by their infrastructure. A provider's session timeout can disqualify an otherwise suitable boundary. The sixth criterion is run-level attribution and observability, covering the harness, model, credential, duration, and output. Without that record, teams cannot fully audit what they spend or link isolated execution to what actually shipped.
How existing workflow integrations interact with the isolation requirement
A sound VM boundary does not secure an entire workflow. If a Slack-triggered task passes credentials in plaintext, or a result posted to Linear bypasses review, the compute boundary cannot repair that failure. Trigger and return paths need governance too. Teams must therefore check isolation all the way from the original request to the result waiting for human review.
Linear integrates with Cursor, Codex, and GitHub Copilot while keeping the human as assignee and the agent as contributor. Cursor and Copilot turn issues into pull requests, whereas Codex posts a summary and link so the user can review the task and create the PR separately. That distinction preserves an explicit human handoff. Claude Code's Slack integration likewise lets teams keep tasks and results in the communication workflows they already use. Where native integrations are absent, a separate interface can reduce adoption and create an unobserved channel outside the team's governance model.
What teams running isolated-VM agents in production have learned
Doctolib illustrates the governance question of where shared standards live. It rolled Claude Code out across its development team after an engineering pilot, with self-onboarding in under five minutes from VS Code, JetBrains, or the command line. Its platform team maintains a shared repository of prompts, custom commands, and subagents that engineers pull during setup. The standards sit inside the harness workflow. This shows how teams share governance rules, though it does not show which isolation primitive governs each run.
Luminous Digital Visions faced parallel execution demands when its client project required simultaneous changes to a React frontend, a Node.js API, and a shared component library. Three Claude Code instances worked in three worktrees and used Agent Teams to coordinate their work. Worktrees alone do not establish VM isolation. For a team with a VM-per-run mandate, the corresponding infrastructure test is whether each instance also has its own isolated execution context.
Rakuten shows how task duration affects session limits and cost modeling. It tested Claude Code on an activation vector extraction method in vLLM, a codebase of roughly twelve and a half million lines. The task took seven hours of autonomous work and achieved 99.9% numerical accuracy. A short session limit would not fit that workload. With a VM-per-run requirement, the execution environment must also stay available for that long.
These examples do not remove the review-debt objection. Faster generation produces more work for engineers responsible for validating the output, and isolated runs returning pull requests can concentrate that burden. Compute isolation does not distribute review capacity. Teams need to plan for that adoption constraint separately from the infrastructure filter, rather than treating successful execution as proof that the whole delivery process can absorb the output.
Applying the filter: how to run a harness evaluation against the isolation criteria
Teams should start the evaluation by asking for the isolation primitive's name and documentation. An answer limited to vendor management, without specifics, is a disqualifying opacity flag. The deployment check comes next. Where the team requires its own VPC, the evaluation must establish whether the harness or underlying sandbox platform can run there before proceeding to feature testing. A hard deployment mismatch has no downstream workaround.
Teams then need written answers on whether the claimed persistence can support the longest task they expect to run. The vendor should distinguish memory checkpoints from filesystem snapshots and disclose session time limits. Governance review then maps credential masking, network egress rules, and approval gates to the available hook and permission surfaces. Any gaps become explicit dependencies on external tooling. This establishes whether policy is enforceable in the proposed environment, rather than merely expressible in a configuration document.
Capacity testing then uses the team's workload profile to model how task durations vary and what it costs to keep VMs alive. Vendor benchmarks are not a substitute for that profile. Before production rollout, attribution checks establish whether telemetry identifies the harness, model, credential, and duration of each run. These checks form a sequential filter that requires infrastructure requirements to be met independently of model quality. When the environment satisfies that contract independently, it becomes the stable layer, and the harness becomes an interchangeable layer above it.
