The moment an engineering team runs more than one Claude Code agent against the same repository, they hit the same wall: two agents editing the same working directory produce conflicts, half-applied changes and test runs that fail for reasons unrelated to the code. Git worktrees solve this cleanly, and they are underused relative to how well they fit the problem.
What a worktree actually gives you
A worktree is an additional working directory attached to the same repository, each checked out to a different branch, sharing one object database. That means no duplicated clone, no separate remote configuration, and no gigabytes of repeated history on disk, but complete isolation of the working files each agent touches. For a large monorepo where a full clone takes several minutes and several gigabytes, that difference is substantial.
Each agent gets its own directory and its own branch, so concurrent edits never collide.
Test runs are isolated, so a failing suite in one worktree tells you something real about that branch rather than about a neighbouring agent's half-finished edit.
Shared object storage means adding a worktree is close to instant, unlike a clone.
Branch state stays visible in one repository, so reviewing what each agent produced does not require hopping between checkouts.
The practical setup
The pattern is straightforward: create one worktree per concurrent agent task, each on its own branch off your integration branch, run the agent scoped to that directory, and merge back through your normal review process. The important discipline is that each agent's instructions must reference its own worktree path explicitly, because an agent given an ambiguous path will happily wander into a sibling directory and undo the isolation you set up.
Teams also need a cleanup step. Worktrees accumulate, and an engineer who has run twenty agent tasks over a fortnight without pruning will find stale directories and branches cluttering the repository. A scheduled cleanup that removes worktrees whose branches have merged keeps this manageable.
Where the time actually gets saved
The saving is not primarily in the agent's own runtime, it is in the elimination of a class of failure that costs human attention. Before adopting worktrees, teams running parallel agents spend a meaningful share of engineering time diagnosing conflicts that turn out to be infrastructure artefacts rather than genuine problems, which is the most frustrating category of work available.
A Sydney engineering team we work with runs four concurrent Claude Code agents on routine maintenance work, dependency upgrades, test coverage, documentation, and small refactors, each in its own worktree, overnight. Before the worktree setup they attempted the same thing sequentially and completed roughly one task per night. The parallel setup does four, at an additional inference cost of around $340 AUD a month against roughly three engineer-days a month recovered.
Choosing what to run in parallel
Not every task is a good candidate for concurrent agent work. Tasks that touch disjoint parts of the codebase parallelise cleanly. Tasks that all modify the same shared module produce four branches that each conflict with the other three at merge time, which converts a concurrency win into a merge burden. The selection discipline matters as much as the worktree setup itself.
The practical heuristic Australian teams use: parallelise across directories or services, sequence within them. Dependency upgrades, documentation, and test coverage for three separate services are ideal concurrent candidates. Four different refactors of the same authentication module are not, regardless of how well isolated the working directories are.
When not to bother
If your team runs one agent at a time, worktrees add process for no benefit and a plain branch is fine. If your repository is small enough that a clone takes seconds and megabytes, a clone per agent is simpler and equally effective. The setup earns its place specifically in the combination of a large repository and genuine concurrency, which describes a meaningful share of Australian mid-market engineering teams but by no means all of them.
A note on guardrails
Isolation between worktrees is not a security boundary. An agent with filesystem access can reach outside its worktree, and worktrees do not change that. If you are running agents unattended against a repository containing anything sensitive, the isolation you need comes from permission scoping and pre-tool-use hooks constraining what the agent can touch, with worktrees handling the separate problem of concurrent edits. Conflating the two leads teams to assume a safety property they do not have.
Used for what it is, a cheap way to run parallel agents without them stepping on each other, the worktree pattern is one of the more straightforward improvements available to an Australian engineering team already running Claude Code at any real concurrency.
