A year ago, most developers ran one AI coding agent at a time. Now a growing number are running three to five simultaneously on the same codebase, and a Git feature from 2015 has become the key enabler.
Git worktrees (git worktree add) create separate working directories that share the same repository history but operate on independent branches. Each directory gets its own files, its own uncommitted changes, and its own branch. No copying the repo. No separate clones eating disk space. The .git object database is shared.
The pattern is simple: create a worktree per agent, point each Claude Code or Codex instance at its own worktree, let them work in isolation, then merge the branches when they finish. The practical ceiling is around five to seven concurrent agents before rate limits and merge conflicts eat into the time savings.
The Tooling That Grew Up Around It
Several multiplexer tools have appeared in early 2026 to manage the workflow. Amux (from Mixpeek) is the most feature-complete: a Python-based Claude Code orchestrator with a web dashboard, SQLite-backed task board with atomic claiming so agents do not duplicate work, and a self-healing watchdog that auto-compacts context when it drops below 20%. Dmux gives every terminal pane its own worktree automatically. Worktrunk is a CLI built specifically for worktree lifecycle management in AI agent workflows.
Claude Code, OpenAI Codex, Gemini CLI, Cursor, and Windsurf all work with worktrees since they just need a normal directory to operate in.
When It Works and When It Does Not
The decomposition has to be right. Independent subsystems like an API endpoint, a UI component, a test suite, and a database migration can run in parallel. But if Agent B needs to import something Agent A is building, they cannot run simultaneously. Bad decomposition creates merge conflicts that take longer to resolve than the parallelism saved.
Google Research data cited in the community suggests multi-agent coordination shows 81% gains on parallelizable tasks but 70% losses on sequential or dependent ones. The practical breakeven point is roughly 30 minutes of sequential work. Below that, the setup overhead of creating worktrees, launching agents, and reviewing results means a single agent is faster.
Each agent also starts with zero knowledge of what the others are doing. There is no shared memory between sessions. You either specify everything upfront or accept that you will spend time on integration work at merge time. For teams already comfortable with feature branches and code review, this maps cleanly to existing workflows. For solo developers, it is a new coordination burden that may or may not pay off depending on project structure.