Runners and Infrastructure: Where AI Coding Agents Actually Run

Published July 27, 2026 · by the AQ team

A runner is the machine where an AI coding agent actually executes: the filesystem that holds your repository clone, the shell that runs its commands, the credentials it pushes code with, and the network position it reaches other services from. Every agentic coding platform has one, whether it calls it a runner, a worker, a sandbox, an environment, or a machine. As of July 2026 the industry has settled on three placements for it: the vendor's cloud, your infrastructure running a vendor's worker process, or infrastructure that is simply yours. Which placement you are on decides where your code and secrets live, what the agent can reach, and who fixes the machine when it breaks.

The runner is one piece of three, and the one with the highest stakes

An agent platform separates into orchestration (the dashboard, session management, and routing), inference (the model reasoning about your code), and execution (the runner this page is about). In most commercial setups those live in three different places: inference is almost always a hosted API, orchestration is usually the vendor's service, and execution is the piece vendors increasingly let you place, because it is where the custody stakes concentrate. Our self-hosted agents guide covers the model and harness layers; here we stay on the execution machine.

Placement 1: the vendor's cloud

The default for every cloud agent product is a machine the vendor provisions, uses for the task, and throws away:

• OpenAI's Codex cloud runs each task in an ephemeral container started from its codex-universal base image. Setup scripts run with network access to install dependencies, then the agent phase runs with internet access blocked by default, per environment settings, as of July 2026.
• GitHub Copilot coding agent works inside an ephemeral development environment powered by GitHub Actions, on a fresh GitHub-hosted runner per task by default.
• Claude Code on the web runs each session in an isolated Anthropic-managed VM, with a proxy holding git credentials outside the sandbox and issuing scoped credentials into it, as of July 2026.
• Cursor's cloud agents run in isolated VMs in Cursor's cloud by default, and Devin boots each session from a saved machine snapshot into its own VM.

The appeal is zero operations. The cost is custody: your checkout, build outputs, and task secrets exist on hardware you cannot inspect, under the vendor's network policy rather than yours.

Placement 2: your machines, the vendor's worker

Since late 2025 the major platforms have converged on a second pattern: a worker process you run on your own infrastructure, connecting outbound to the vendor (HTTPS only, no inbound ports) and executing the agent's tool calls locally while planning and inference stay in the vendor's cloud.

• Copilot coding agent gained self-hosted runner support in October 2025: the agent's environment runs on your own ephemeral GitHub Actions runners managed by Actions Runner Controller, reaching internal packages and services that are not on the public internet.
• Cursor's self-hosted cloud agents, announced March 2026 for Enterprise plans, keep your codebase, tool execution, and build artifacts in your environment; workers can be long-lived or single-use, with a Helm chart and Kubernetes operator for large fleets.
• Warp's Oz offers an oz-agent-worker daemon on its Enterprise plan that executes tasks in Docker containers, Kubernetes Jobs, or directly on the host. Warp's docs are direct that session transcripts, including code context, and LLM inference still route through Warp's servers under Zero Data Retention agreements, as of July 2026.
• Devin Outposts lets a worker on your VM, Kubernetes cluster, or even a desk-side machine claim sessions and execute every command and file edit locally while Devin's agent loop stays in Cognition's cloud.

Read the boundary carefully: this pattern keeps code artifacts on your machines, but prompts containing code context still flow through the vendor's orchestration and out to the model provider. It answers "our repository never leaves our network." It does not answer "nothing derived from our source leaves our network."

Placement 3: infrastructure that is simply yours

The third placement skips the vendor worker entirely: a VM you provision, with agent CLIs like Claude Code and Codex installed directly, kept alive with tmux, reached over SSH. There is no platform in the execution path; the CLIs talk straight to the model APIs under your own accounts. Our guide to running Claude Code on a cloud VM walks through the setup. It is the cheapest and most private placement, and the one where every operational duty lands on you.

What actually lives on a runner

Whatever the placement, the same five things accumulate on the execution machine. They are the custody question in concrete form:

• The working checkout. Not just the repository: uncommitted changes, half-finished work the agent has not pushed anywhere yet.
• Credentials. A GitHub token that can push, the agent CLI's own login, any database URLs or API keys tasks need.
• Session state. The running terminal itself. On persistent machines this is often in-memory (a tmux server), which a reboot clears.
• Build artifacts and caches. Dependency directories and build outputs, which both leak information about your code and quietly consume disk.
• Network position. Whatever the machine can reach (staging databases, internal registries, your VPN), the agent can reach.

Ephemeral or persistent

CI taught the industry that ephemeral runners are the safer default: GitHub recommends only using Copilot coding agent with single-use runners, because a reused runner accumulates state an earlier job can poison. Vendor-cloud agent products inherit this design, tearing the container or VM down when the task ends.

But an interactive coding agent session is not a CI job. Sessions run for hours or days, hold conversation context worth keeping, and benefit from warm state: dependencies installed, the dev server running, the agent mid-task exactly where you left it. That is why persistent runners dominate placement 3, and why persistent placements isolate per task (typically one git worktree per workspace) instead of using a fresh machine per task.

Operating a persistent runner: health is the whole job

A persistent runner fails in boring, predictable ways: the machine stops or the connecting daemon dies and nobody notices until a session hangs; the disk fills with old checkouts and dependency directories; a credential expires; orphaned processes pile up. Ephemeral fleets sidestep this by replacing machines instead of repairing them. A persistent placement has to face it with tooling, and the checklist for evaluating any platform (or your own scripts) is short: does setup verify the machine is actually usable before the first task, is the runner's health visible where the team works rather than only over SSH, and when something is wrong, is there a single diagnostic that says what?

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. In this page's terms, AQ is a persistent placement-3 runner with the operations tooling built in, and the runner is always a specific team's own machine: there is no shared multi-tenant execution tier.

The two plans are the two ways to own that machine. On the Free plan you bring your own VM and pay only your cloud provider; the full product runs against it. On the Team plan ($100 per user per month promotional, standard $200, billed monthly) AQ manages a dedicated always-on VM for your team in its own isolated network, with your rate locked for your first 12 months. Either way, the runner holds exactly what this page enumerates: agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions streamed live to the browser, each engineer signs into the CLIs with their own Claude or OpenAI account (AQ never marks up model usage), GitHub access is per user, and every workspace gets its own isolated git worktree (branch ai/{id}-{slug}, automatic dependency install, one-click rebase onto main) so parallel tasks never collide.

Persistence is the point: sessions survive a closed laptop and resume from any device, and a teammate can open the same workspace and see and steer the same live session. And because a persistent runner needs health tooling, AQ ships the checklist above: the installer runs preflight checks before the first workspace, runner health is visible in the product itself, and an aq-runner doctor command diagnoses a broken host from the machine's side.

If you want a vendor-managed ephemeral container per task, the platforms in placement 1 do that well. AQ is for teams that want long-lived agent sessions on a machine they control, visible to the whole team, without writing the glue themselves.