Self-hosted Coding Agent Runtime Comparison Guide

The right self-hosted coding agent runtime is the one that matches your trust boundary. For most security-conscious teams, that means per-task isolated workspaces, no raw secrets inside the agent process, outbound traffic through an allowlisted proxy, and command, network, and artifact logs that are complete enough to support review. Local CLI agents are useful for developer flow, but they should not be treated as an enterprise isolation model by themselves.

The decision is less about whether Claude Code, Codex, OpenCode, or a Copilot-style agent is more capable. The harder question is where autonomous code execution should run, what it can read, what it can reach, and what you can prove after it finishes. A runtime is the layer that clones repositories, installs dependencies, runs tests, manages branches, preserves or destroys state, records activity, and applies policy.

The five runtime options

There are five practical patterns in the current market.

Local CLI on a developer host. This is the fastest path to adoption. Claude Code, Codex CLI, and OpenCode can work directly in a local checkout with the same tools a developer uses. The trade-off is clear: the agent inherits the host user's files, credentials, network access, SSH keys, cloud CLIs, package tokens, and reachable internal systems unless you wrap it.

Managed cloud coding agent. Codex cloud and GitHub Copilot cloud agent move work into vendor-managed environments. They can offer background execution, pull request workflows, logs, diffs, and less infrastructure to operate, depending on product and plan. In exchange, repo content, task context, environment configuration, and some control-plane behavior move into a vendor data plane.

Docker worker or sandbox. Containers are familiar, automatable, and easy to standardize across teams. Docker Sandboxes add a stronger productized pattern around agent execution, including host proxying and restrictions on host filesystem, host network, localhost, other sandboxes, and non-allowlisted domains. The details matter: a direct workspace mount is live read-write, while clone mode gives the sandbox a private copy and mounts the repo read-only.

VM, microVM, or gVisor-style isolation. This is the stronger boundary for untrusted repositories, external contributors, or multi-tenant agent fleets. It costs more in image management, startup behavior, disk state, debugging, and proxy plumbing, but it gives security teams a more defensible kernel boundary than a plain container.

Self-hosted multi-agent control plane. Platforms such as Multica, Docker Agent harnesses, OpenHands-style deployments, and custom Kubernetes or microVM systems add queues, team UI, resumability, artifacts, agent routing, and audit hooks. They can route tasks to Claude Code, Codex, OpenCode, Copilot CLI, or other drivers. The cost is ownership: upgrades, runner capacity, tenancy, secrets, flaky driver behavior, and incident response become your platform problem.

Comparison matrix

Permission prompts are not a security boundary

This is the most important design point. CLI permission models reduce accidental damage, but they are not a substitute for isolation. The research brief cites Claude secure deployment guidance that describes command permissions as "a permission gate, not a sandbox." That distinction should drive your architecture.

Claude Code sandboxing can restrict sandboxed Bash writes to the working directory and a session temp directory by default, with prompts for new network domains. Codex CLI exposes sandbox modes such as read-only, workspace-write, and danger-full-access, plus approval modes. OpenCode supports agent profiles with defaults such as ask for file edits and Bash in planning mode, read-only exploration, or broader tool access for general agents.

Those controls are useful UX and policy levers. They do not solve the full problem of a compromised dependency script, prompt-injected issue, malicious test fixture, or overeager agent operating with broad local access. Auto-approve or full-access modes belong inside an external sandbox, not on a normal developer workstation with production credentials nearby.

Where managed cloud agents fit

Managed cloud agents are attractive because they package the workflow that enterprises would otherwise build: checkout, setup, execution loop, diff, logs, review, and pull request integration. Codex cloud creates a container, checks out the selected repo branch or commit, runs setup, applies internet settings, lets the agent edit and run checks, then returns a diff. Its internet access is off by default during the agent phase, with allowlist controls available per environment.

GitHub Copilot cloud agent runs in an ephemeral GitHub Actions-powered development environment. It can plan, change branches, open pull requests, and expose steps through commits and logs. That fits organizations already centered on GitHub workflows. The caveat is that firewall behavior and runner controls are specific. The brief notes that GitHub's integrated firewall is not a complete security solution and is not compatible with self-hosted runners in the enterprise cloud variant, which means teams using internal runners must supply network policy externally.

The strategic trade-off is control-plane ownership. Managed cloud reduces infrastructure work, but you must accept the vendor's boundaries for data residency, repo permissions, secrets, egress, audit exports, and retention.

Docker, VM, and microVM patterns

Docker is the pragmatic middle ground. It is familiar to platform teams, works well with queues and CI-style jobs, and can standardize dependencies. But plain Docker is only as good as its mounts, seccomp profile, network policy, user mapping, and host configuration. Exposing the Docker socket to an agent is a critical anti-pattern because it can become host control.

Docker Sandboxes point to a more opinionated model for Claude Code, Codex, and OpenCode. The agent cannot access host filesystem outside the workspace, the host Docker daemon, host localhost, other sandboxes, or domains outside the allowlist. Raw TCP, UDP, and ICMP are blocked. Sandbox state persists until removal, including packages, Docker images, containers, agent history, and workspace changes. That persistence speeds repeat work but increases blast radius if secrets or poisoned state land on disk.

For higher-risk workloads, use gVisor, VMs, or microVMs. The brief notes vendor guidance that places VMs and gVisor above containers for isolation when correctly configured, with higher overhead and complexity. That is the normal security trade-off: stronger boundaries cost more operationally.

Self-hosted coding agent runtime reference architecture

A defensible self-hosted coding agent runtime has seven parts:

• Task queue: accepts work from Slack, GitHub, Jira, or an internal portal and assigns each task to a fresh runtime.
• Per-task workspace: creates an ephemeral or explicitly resumable checkout with a clear retention policy.
• Runtime boundary: uses hardened Docker, gVisor, VM, or microVM isolation depending on repo risk and tenancy.
• Egress proxy: defaults to deny, allows package registries and approved services, and records network requests.
• Secret broker: keeps raw credentials outside the agent boundary and injects only scoped, per-task capability through proxy or mediated tools.
• Audit pipeline: captures commands, tool calls, diffs, approvals, network logs, artifacts, token usage, and runner time.
• Cost ledger: attributes model tokens, runner minutes, sandbox hours, storage, and parallel attempts to repo, team, and task.

This architecture also makes driver portability realistic without pretending it is complete. Claude Code, Codex, OpenCode, and Copilot-style tools differ in permission flags, MCP paths, resume identifiers, transcript behavior, token reporting, and network assumptions. A control plane can normalize the task lifecycle, but it cannot erase those driver-level differences.

Buying and build checklist

Use this checklist before approving a runtime for broad use:

• Can every task run in a fresh or explicitly resumable workspace?
• Can the agent read raw secrets, or only call mediated tools?
• Is outbound traffic denied by default during the agent phase?
• Are dependency registries allowlisted without broad wildcard access?
• Are command, network, tool, approval, and diff logs retained?
• Can you attribute cost per repo, task, team, and provider?
• Can the runtime support Claude Code, Codex, OpenCode, or Copilot-style agents without losing policy visibility?
• Are long-lived workspaces scanned, reset, or destroyed on schedule?
• Is the Docker socket unavailable to the agent?
• Can security reproduce what happened after a bad change or suspected exfiltration attempt?

Red flags

Reject designs where agents run with broad cloud credentials, unrestricted internet, shared writable volumes, host SSH agent forwarding, invisible package installs, or no per-task logs. Treat "self-hosted" as a deployment location, not a security property. A poorly isolated self-hosted worker on a flat internal network can be riskier than a managed cloud agent with default firewalling and clean audit trails.

The practical answer is conditional. For individual developers, local CLI agents are acceptable when scoped to low-risk repos and reviewed changes. For platform teams, hardened Docker or Docker Sandbox-style runtimes are the usual starting point. For regulated, multi-tenant, or untrusted workloads, move to VM or microVM isolation. For organizations standardizing agent work across many teams, build or buy a control plane only after you can operate the isolation, secrets, egress, logging, and cost layers as first-class platform services.