Skip to main content
bex.co
419
Blog

GitHub Copilot's Worktree Isolation Is Not a Sandbox — Why That Matters for Deploy-Authority Agents

8 min readDora NodaDora Noda
GitHub Copilot
Self-Hosting
PaaS
Model Context Protocol
Security
Share
On this page

On June 17, 2026, GitHub took the Copilot app out of technical preview and made it generally available on macOS, Windows, and Linux. The headline feature is parallelism: run up to ten coding-agent sessions against the same repository at once, each one tracked in a "My Work" view alongside issues, pull requests, and background automations. The mechanism that makes that safe is deceptively simple — every session gets its own git worktree, a real checkout of the branch, created and torn down automatically with no manual setup.

That's a specific, load-bearing design choice, and it's a different one than the sandbox-infrastructure vendors have been making. E2B boots a dedicated Firecracker microVM per session, with its own kernel, in around 150ms. Daytona does the same with containers in around 90ms, before going closed-source in June 2026 over what it described as security concerns with its own approach. GitHub's answer is neither: no microVM, no container, just a worktree on the same host, sharing the same Docker daemon, the same database, the same filesystem everything else on that machine already trusts. For a coding assistant proposing diffs, that's a reasonable trade. For a platform whose agents don't just propose changes but execute deploy, rollback, and scale against real tenant infrastructure through an MCP server, it's a materially different bet — and worth working through concretely before copying it.

What a Worktree Actually Buys You​

The honest case for worktree isolation isn't speed on a stopwatch — nobody has published a clean "worktree creation vs. microVM boot" benchmark, and the comparison would be apples to oranges anyway. The real case is that there's no separate infrastructure to run at all.

E2B and Daytona both require a sandbox fleet: a pool of machines or containers to provision, keep warm, meter, and pay for, sitting behind an API a session calls into before it can do anything. A worktree needs none of that. git worktree add is a local filesystem operation against a repo you already have checked out — it reuses the object store, reuses the developer's already-authenticated environment (installed dependencies, cached node_modules, a logged-in gh CLI, an SSH agent with the right keys), and starts working immediately. GitHub's own framing is explicit about this: the app "handles every worktree for you — no manual setup, no cleanup, no branch juggling." That's the shared-filesystem trust developers already have, and it's real: for ten parallel sessions doing nothing more dangerous than editing files and running a local test suite, standing up a Firecracker fleet to get hardware-level isolation is solving a problem those sessions don't have.

What It Doesn't Buy You​

The same shared filesystem that makes worktrees cheap is also where the isolation stops. A worktree gives every session its own working directory and branch checkout — but all of them still share one .git directory, one Docker daemon, one Postgres instance, one set of default ports.

That's not a hypothetical gap; it shows up in exactly the ways you'd expect once more than a couple of sessions run at once:

  • Port collisions. Dev servers default to the same ports — 3000, 5432, 8080 — across every worktree on the box. Nothing stops two parallel sessions from fighting over the same one.
  • Shared git state. The .git directory and its index are shared across all worktrees on a repo. Concurrent writes to that index from parallel sessions are a known source of silent corruption — the kind of bug you don't discover until the state it quietly dropped turns out to matter.
  • One Docker daemon, one database. If a session's task involves running a multi-service stack, every other session on the same box is contending for the same daemon and the same database connections, unless something outside the worktree model isolates them.

None of this is a defect in GitHub's implementation — it's the direct, unavoidable consequence of choosing "isolate the file tree" over "isolate the machine." A worktree solves code isolation. It does not solve environment isolation, resource isolation, or network isolation, and GitHub isn't claiming otherwise.

The Two Alternatives Already on the Table​

Two harder isolation boundaries already exist, and both work by giving up the zero-infrastructure property a worktree has in exchange for a real security boundary.

Rented microVM/container sandboxes. E2B's Firecracker microVMs give every sandbox its own kernel — isolation at the hardware level, not the process level — at around 150ms per cold start. Daytona's container-based sandboxes start faster, around 90ms, at the cost of a shallower isolation boundary (shared kernel, namespace-level separation rather than a dedicated one). Both charge for it: sandbox compute is metered, separate from whatever's running the agent itself.

Kubernetes-native sandbox CRDs. kubernetes-sigs/agent-sandbox takes a third approach: a sandbox as a declarative Kubernetes object, scheduled and torn down by the same control plane already managing the rest of a fleet. AgentBox — a 247-star, MIT-licensed CLI — is the lightweight, self-hosted version of the same idea, and notably already lists a bare Hetzner box as a first-class provider alongside E2B and Daytona in its support matrix, using checkpoint and credential-isolation mechanisms to get sandbox-like guarantees without a dedicated sandbox vendor underneath.

Both of these cost more to run than a worktree. Both also draw a boundary a worktree structurally cannot: one session's execution can't reach into another's kernel, daemon, or credentials, because there's no shared daemon or credential store to reach into in the first place.

Why the Stakes Are Different for a Deploy-Authority MCP Server​

For GitHub's use case, the worktree trade-off is the right one. The worst case when isolation fails is a messy merge conflict or a corrupted git index — annoying, recoverable, contained to one repo on one developer's machine.

That calculus inverts the moment an agent's tool call doesn't just edit files but executes against live infrastructure. A deploy-from-chat platform's MCP server is exactly that case: a deploy, rollback, or scale call isn't a proposed diff a human reviews before it lands — it's an action that already happened against a tenant's Cluster-API-provisioned fleet by the time the call returns. If two agent sessions handling two different tenants' deploy requests share a Docker daemon, a credential store, or a network path the way two Copilot worktree sessions share a .git directory, the failure mode isn't a silent git corruption bug — it's one tenant's session touching another tenant's infrastructure, or a single compromised or misbehaving session having a blast radius that reaches every other tenant on the same host.

Worktree-level isolation was never built to prevent that, because the problem it solves — don't let concurrent file edits stomp on each other — isn't the problem a deploy-authority tool call has. The problem a deploy-authority tool call has is the one E2B, Daytona, and kubernetes-sigs/agent-sandbox were built for: don't let one execution reach resources that belong to another.

What This Means for bex's Own MCP Roadmap​

The useful takeaway isn't "worktrees are wrong" — it's that isolation choice should track what the tool call actually does, not get set once for every agent action a platform exposes:

  • Code-proposal tools — an agent drafting a config change, a Dockerfile edit, a bex.yml update for review — fit the worktree model fine. The worst case is contained to a git repo, and the zero-infrastructure cost is a genuine win worth taking.
  • Deploy-authority tools — deploy, rollback, scale, anything that executes against a tenant's running fleet the moment the call returns — need the harder boundary: an ephemeral, torn-down-after-use execution context with no daemon, credential, or network path shared across tenants. That's the E2B/Daytona/Kubernetes-CRD category, not the worktree category, and it's worth the extra infrastructure cost precisely because the blast radius of getting it wrong is someone else's production traffic.

GitHub's worktree bet is a sound answer to the question it was actually asked. A platform whose MCP server holds deploy authority over real tenant infrastructure is being asked a harder question, and it needs the harder answer — chosen deliberately, tool call by tool call, rather than inherited by default from whichever primitive shipped first.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.

Sources​

Related articles

Give your agents a chain backend

Autonomous agents hit RPC endpoints very differently than people do. See what bex router handles on their behalf.

Read the agents guide
Back to all posts