If you’ve run more than one AI coding agent against the same repo at the same time, you already know the failure mode: agent A checks out a branch, starts editing, agent B (same repo, same working directory) checks out a different branch mid-session, and now agent A’s uncommitted changes are sitting on the wrong branch — or worse, silently gone. On August 7, 2026, GitHub shipped a fix that’s less a feature than an overdue acknowledgment: Copilot, Claude, and Codex agent sessions in VS Code now each get an isolated git worktree, plus “peer chat” forking and /side parallel-question sessions that don’t blow away your main conversation’s context.

The Problem With Concurrent AI Agent Sessions

Every AI coding agent needs a working directory to edit files, run tests, and inspect diffs. Before this change, the default was one shared working directory per repo — fine when you’re running a single agent, catastrophic when you’re not. Multi-agent workflows are now common enough that this stopped being an edge case: kick off a refactor with Claude, ask Copilot to draft tests in parallel, and have Codex investigate a flaky CI failure — all against the same checkout — and you were one git checkout away from cross-contaminating three unrelated diffs.

Teams worked around this manually, usually with hand-rolled git worktree scripts wired into shell aliases. That’s exactly what GitHub baked into the editor.

What Actually Shipped

Each agent session now gets its own worktree, created and torn down by VS Code:

# what VS Code now does behind the scenes when you start an agent session
git worktree add ../repo-agent-session-a7f3 -b agent/refactor-auth-a7f3

The agent operates entirely inside that worktree — its own working directory, its own index, sharing the same .git object database as your main checkout. When the session ends (or you discard it), VS Code prunes the worktree:

git worktree remove ../repo-agent-session-a7f3
git worktree prune

You can inspect what’s live at any point the same way you always could:

git worktree list
# /home/dev/repo                        abc1234 [main]
# /home/dev/repo-agent-session-a7f3      def5678 [agent/refactor-auth-a7f3]
# /home/dev/repo-agent-session-b91c      9ab0cde [agent/flaky-ci-investigation]

On top of worktree isolation, GitHub added two chat-level features: peer chat, which forks an existing agent conversation (with full history) into a second session so you can explore an alternative approach without losing the original thread, and /side, a lightweight parallel question you can fire at the same agent without derailing its main task — think “quick, what does this function do” without making the agent lose its place in a multi-step refactor.

Why Worktrees, Not Branches

The obvious naive fix is “just use branches.” The reason that doesn’t work is the working directory itself is the shared resource, not just the ref. Two branches can’t be checked out into one working directory simultaneously — that’s the whole problem. Worktrees solve this at the correct layer: same repository, same object database (so no duplicated .git history, no expensive re-clone), but genuinely separate working directories and indexes. It’s the same primitive senior engineers have used for years to run a hotfix build without stashing an in-progress feature — GitHub just made it the default unit of agent isolation instead of a manual habit.

What This Changes for Team Workflows

Disk and cleanup discipline now matters more. Every concurrent agent session is a full working copy of your repo (worktrees share object storage but not working-tree files). On a large monorepo, five or six live agent sessions can add up fast. Watch for orphaned worktrees from crashed or abandoned sessions — git worktree list and a periodic git worktree prune should go into your team’s routine maintenance, the same way you’d clean up stale feature branches.

Merge conflicts move earlier, not away. Isolation prevents agents from stepping on each other’s working directories, but it does nothing to prevent them from editing the same files in ways that conflict once you try to merge. If you route three agents at the same auth module, you’ll still hit a three-way merge — you’ve just deferred the collision from “silent overwrite during the session” to “conflict at merge time,” which is strictly better but not conflict-free.

Code review needs a per-worktree mental model. If your review tooling assumes one working directory per repo (some local diff/lint tooling does), you may need to explicitly point it at agent/refactor-auth-a7f3’s worktree path rather than assuming HEAD in your main checkout reflects what an agent produced.

The Tradeoffs

This isn’t free. Worktrees still consume real disk for working-tree files, checked-out large binaries multiply per session, and any pre-commit or IDE tooling that hardcodes a single repo path will need to be worktree-aware. None of this is new — it’s the standard cost of git worktree — but “the editor does it automatically for every agent session” means the cost now scales with how many agents you run, not how many worktrees you manually decided to create.

Practical Next Steps for Teams

  1. Set a worktree budget. Decide how many concurrent agent sessions your team’s CI/disk footprint can absorb, and treat orphaned worktrees as a linting problem — script a cleanup check into your dev environment setup.
  2. Route agents by file ownership, not just by task. If two agents might touch the same module, either serialize those tasks or accept you’re buying a merge conflict later.
  3. Point local tooling at the right worktree path — don’t assume . is where the agent’s changes live.
  4. Use /side for genuinely quick questions, and reserve peer-chat forking for real “let’s try a different approach” moments — both are cheap, but forking a full session history isn’t free context to carry around either.

The Broader Trend

This is the same pattern we’re seeing across the AI tooling stack: primitives that used to be manual habits for careful engineers (worktrees, sandboxed environments, isolated credentials) are becoming default infrastructure the moment AI agents make concurrency the norm instead of the exception. The interesting long-term question isn’t whether your editor isolates agent sessions — it’s whether your team’s review, CI, and merge processes are ready for “three agents editing the same repo right now” to be a Tuesday, not an incident.

Thuận Lương is a Technical Lead with 15+ years in .NET, cloud architecture, and AI systems. He writes about real-world lessons from building production systems.

Export for reading

Comments