AI Coding Agent Workspaces: How Isolation and Lifecycle Work

Published July 20, 2026 · by the AQ team

A coding agent workspace is the isolated slice of a codebase, plus the running session and status around it, that one AI coding task occupies from creation to cleanup: a separate checkout so concurrent tasks cannot overwrite each other's files, a session (terminal, container, or VM) that holds the work in progress, and a lifecycle state that tracks whether the task is still running, waiting on review, or finished. Every agentic coding platform needs some version of this, whether it calls the unit a workspace, a session, a task, or a machine, because letting two agents edit the same working directory at the same time corrupts the codebase.

Why isolation is not optional once agents run concurrently

One agent editing one checkout is safe by default: it is the same thing a human developer does. The problem starts the moment a second task begins before the first finishes. Two processes writing to the same files, running the same test suite, or checking out the same branch will race, and the failure mode is not a crash, it is silently wrong code. Every platform that lets you run more than one agent task at a time has had to solve this, and they have converged on a small number of answers.

Three ways platforms isolate a workspace

Strip away branding and there are three underlying isolation strategies, trading spin-up speed and cost against how strong the boundary is:

• A dedicated VM per task. Cursor's Cloud Agent (formerly Background Agent) spins up its own Ubuntu VM per task as of July 2026, clones the repository fresh, and works on an agent/<task-slug> branch; Devin does something similar, resetting each session to a saved machine state and, for delegated sub-tasks, running each "managed Devin" in its own isolated VM with its own terminal and browser. Strongest isolation, slowest and most expensive to provision.
• A container per task. OpenAI's Codex Cloud runs every task in an ephemeral container built from a base image (codex-universal) that defines the repository, dependencies, secrets, and network policy for that run, and destroys the container when the task ends. OpenHands takes the same shape self-hosted: a controller process spawns a Docker sandbox per session (Kata Containers, Firecracker, or gVisor are documented alternatives for stricter isolation), and the agent's shell commands and file writes happen inside that sandbox, not on the host. Faster than a full VM, still a real process and filesystem boundary.
• A git worktree on shared infrastructure. Claude Code shipped native --worktree support in version 2.1.49 (February 2026), creating an isolated checkout under .claude/worktrees/ with its own branch, scoped to one session. Conductor, a Mac app for running parallel Claude Code and Codex sessions, makes a git worktree the workspace itself: each one gets its own checkout and branch while sharing the parent repository's history, refs, and object database, so creating a new workspace does not mean cloning the repo again. Cheapest and fastest to create; the isolation is at the filesystem and branch level, not the process or machine level, so several worktrees still share one host's CPU, memory, and any credentials available on that host.

The git worktree pattern, in more detail

A worktree is a second working directory attached to the same git repository: same commit history, same remotes, same object database, but its own files on disk and its own checked-out branch. That is why it is the cheapest isolation primitive on this list, but it is also why teams that lean on worktrees run into a specific set of problems once they accumulate: deleting a worktree directory by hand (instead of running git worktree remove) leaves a stale administrative entry behind, git still considers the branch checked out elsewhere, and later commands fail with a confusing "branch is already checked out" error. Left unmanaged, worktree count and disk usage climb quietly; teams have reported hundreds of stale worktrees consuming tens of gigabytes, most referencing branches merged months earlier. git worktree prune clears orphaned administrative entries, and treating cleanup as part of a task's completion, not a separate chore, avoids the pile-up in the first place.

# Safe teardown once a task's branch is merged or abandoned
git worktree remove path/to/worktree   # not rm -rf
git worktree prune                     # clear any stale entries left behind

Lifecycle: the states a workspace moves through

Regardless of isolation strategy, a workspace's lifecycle has the same four stages:

• Creation. Triggered by a human starting a task, a labeled issue, or an existing PR or branch. This is where the checkout, container, or VM gets provisioned.
• Active. The session is running: the agent is reading code, running commands, and committing. This is the stage worth making visible and shareable, since it is the only stage a reviewer can meaningfully watch.
• Signal of completion. A PR opens, a task gets marked done, or a human stops the session. Platforms differ on how explicit this is: some just leave the session idle, others move a linked ticket to a done column automatically.
• Cleanup. The container is destroyed, the VM is decommissioned, or the worktree is removed. Ephemeral backends (Codex Cloud's containers, Cursor's per-task VMs) do this automatically once the task ends. Worktree-based and persistent-VM setups need either a deliberate teardown step or a periodic sweep, since nothing forces it to happen on its own.

The practical difference that matters when you are picking a platform is whether cleanup is automatic or something your team has to remember to do, and whether "active" survives you closing your laptop or dropping your SSH connection. A session tied to your local machine's process table ends when that process ends; a session on a VM or in a cloud container keeps running.

What this term does not mean by itself

"Workspace" is not a standardized word in this space; it usually just means "the isolation and state around one task," and every vendor's marketing calls it something slightly different (session, machine, task, environment). When comparing tools, the specific questions that matter are: is the isolation a full VM, a container, or a worktree; does the session survive your laptop closing; is cleanup automatic or your job; and can more than one person actually see and interact with the same running session, or is it single-player by design.

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. A workspace in AQ is the unit this whole page has been describing, made explicit: 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 on files, and each workspace's status is either active or closed rather than a single unlabeled session that quietly goes stale.

The difference from the plain worktree pattern above is what runs inside the workspace and who can reach it. Agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in a persistent session on your team's own VM, so a workspace survives you closing your laptop the same way a cloud VM or container would, without giving up the low overhead of a worktree. Any teammate with access can open that same workspace and see and steer the same live session instead of inheriting a finished diff, each person signs into the CLIs with their own account, and agents commit, push, and open pull requests through each user's own GitHub access, with every PR tracked against its workspace. Work can enter a workspace from a manual prompt, a GitHub PR or branch, or a Linear issue labeled ai-task, and there is no shared multi-tenant execution tier: your workspaces run on your VM, whether that is a dedicated AQ-managed machine on the Team plan or one you connect yourself on the Free plan.

If you are one person running Claude Code on your own laptop, a plain --worktree session is enough, and this page's worktree section covers exactly how to set that up. AQ's workspace model earns its place once a second person needs to see the same session, or the task needs to keep running after you disconnect.