How to Limit What a Coding Agent Can Destroy

Published September 11, 2026 · by the AQ team

You limit what a coding agent can destroy by deciding its unit of damage before you start it, not by hoping to catch mistakes afterward. Five boundaries do the work: a git worktree per agent so a bad edit ruins one directory instead of your checkout, a branch only that agent writes to so main is never in the blast zone, a sandboxed shell so the operating system (not the model's judgment) decides what it can touch, scoped credentials so the worst command is bounded by the worst token, and a real undo path for what slips through. Review comes last and is the weakest layer, because review only sees the diff: a runaway command does its damage at run time, long before anyone opens a pull request.

Why this is a containment problem, not a trust problem

The past year supplied enough public incidents to retire the idea that careful prompting is a safety strategy: an agent asked to clean up an old repository ran an rm -rf whose argument list ended with a trailing ~/ and wiped the user's home directory, and agents holding live database credentials have dropped production data mid-task. In every case the agent was not malicious; it was wrong once, and nothing stood between being wrong and the damage. A system where one bad tool call equals unbounded loss is a bad system whatever the model's error rate. The goal is to make the worst case boring: one branch, one directory, or one throwaway machine, never your repository or your production database. That matters more as agents run in parallel or overnight, where failures are routine.

Layer 1: one worktree per agent makes the filesystem the unit of damage

A git worktree is a second working directory checked out from the same repository, sharing one object store. Give every agent its own worktree on its own branch and the filesystem blast radius collapses to one directory: an agent that corrupts files has ruined a checkout you can recreate in seconds, while your working copy and every other agent's stay untouched.

# One isolated checkout per agent task
git worktree add ../agent-fix-auth -b agent/fix-auth
cd ../agent-fix-auth   # start the agent here, not in your main checkout

# If the agent ruins it: throw the whole thing away
git worktree remove --force ../agent-fix-auth
git branch -D agent/fix-auth

Two caveats keep this honest. Worktrees isolate files, not processes: agents can still fight over port 3000 or a shared test database, which is why parallel sessions collide even when their files never do. And uncommitted work in a deleted worktree is gone, an argument for the checkpoint layer below. The full worktree guide covers naming, cleanup, and per-worktree dependency installs.

Layer 2: a branch the agent can only trash itself

An agent that only ever writes to agent/fix-auth can produce garbage commits or rewrite its own history, and the cost is one branch nobody depends on. What turns branch mistakes into repository mistakes is shared write access: agents committing to main, two agents on one branch, an unprotected default branch. Branch protection on main (no direct pushes, no force pushes, PRs only) is the cheapest control on this list, because the host enforces it rather than the agent's compliance. The remote is your backstop: an agent can destroy anything on its machine, but not commits already pushed to a remote it cannot force-push.

Layer 3: sandbox the shell so the OS enforces the boundary

Worktrees and branches constrain git. They do nothing about rm, curl, or a package script with side effects, because a shell command does not care where your checkout boundary is. That is what OS-level sandboxing is for, and as of September 2026 the major CLIs ship it.

Claude Code's sandboxed Bash tool has the operating system enforce the boundary for every command and its child processes (Seatbelt on macOS, bubblewrap on Linux): by default, writes are confined to the working directory and a session temp directory, reads can be restricted with deny rules that mask credential files, and network egress is confined to a domain allowlist. Codex likewise sandboxes commands: its workspace-write mode confines edits to the workspace with network access off by default, and out-of-boundary actions surface as approval requests. The shared design is the point: the agent proposes, the OS disposes, and a hallucinated path outside the boundary fails instead of executing.

When the work is genuinely untrusted or needs broad system access, move the boundary out one ring: a container, or better, a dedicated VM. A machine holding one repository clone and one scoped token is the cleanest blast radius there is, because there is nothing else on it to destroy: the custody logic of running agents safely on your own repositories.

Layer 4: credentials bound the worst case

An agent's true blast radius is the union of what its machine can reach and what its credentials can do. A perfectly sandboxed agent holding an org-wide GitHub token or a production database URL is still one confused command from a very bad day, because the damage happens on the other end of a legitimate, authenticated API call no filesystem sandbox sees.

• Scope tokens to the task. GitHub's fine-grained personal access tokens can be limited to selected repositories, with per-permission read or write grants and an expiry. An agent fixing one repo needs contents and pull request access to that repo, nothing else.
• Keep production credentials off the agent's machine entirely. If the agent cannot reach production, it cannot destroy production, whatever it decides to run.
• Prefer short-lived credentials issued at use time, and treat anything the agent can read as something that may end up in a prompt: keeping secrets out of agent prompts covers that half.

Layer 5: checkpoints, commits, and honest undo

Undo comes in layers, and the gaps matter more than the features. Claude Code checkpoints the files it edits before each prompt and can rewind code, conversation, or both. But checkpointing tracks the agent's file editing tools, not the world: files modified by shell commands (an rm, an mv, a script) are not captured, and nothing local undoes a remote side effect like an API call or a push. Git commits are the durable layer: commit often on the agent's branch and push it, and the remote holds your history even if the machine is lost. Everything else follows one honest rule: actions with remote side effects are not undoable, so they belong behind the strictest gates above.

What a review gate can and cannot catch

Review is a real layer: it catches logic errors, bad design, and unwanted dependencies before merge. But it sees only the diff, so a command that already hit a live service, leaked a secret, or deleted data outside the repository is invisible to it by construction. And in practice it is thinner than teams assume: a July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans. A gate one person operates alone, at the end, cannot be the plan: containment upstream makes its job tractable, and watching sessions while they run catches what no diff will ever show.

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. Its architecture is this guide's checklist built in. Every workspace gets its own isolated git worktree on its own branch (ai/{id}-{slug}) with automatic dependency install and a one-click rebase onto main, so the filesystem and branch layers are the default rather than a script you maintain. Agents run as real CLIs in persistent tmux sessions on your team's VM, in your own cloud account or on a dedicated AQ-managed VM in its own isolated network, with no shared multi-tenant execution tier.

Credential custody follows the same lines: each engineer signs into the CLIs with their own Claude or OpenAI account (AQ never marks up model usage), and commits, pushes, and PRs use per-user GitHub auth, so an agent acts with one person's scoped identity rather than a shared bot token. The layer AQ adds beyond solo setups is eyes: teammates open the same workspace and watch the same live session as it runs, and typing into someone else's terminal requires the owner to approve a control request in one click. PRs are tracked per workspace, and visibility is owner-managed: team-visible, or private and shared with specific people.

The Free plan is a personal sandbox for one person: AQ creates a private machine in an isolated network, nothing to install, no time limit. The Team plan is $50 per user per month at early access pricing (standard $200, billed monthly), covers VMs you connect from your own cloud or a dedicated always-on AQ-managed VM, with your rate locked for your first 12 months. One engineer with a worktree script and a scoped token can stop at the manual layers above. AQ earns its place when a team wants those layers standard on every session, plus the one control no solo setup has: other people watching.