Influxx never asks two AI coding agents to share one working copy and take turns checking out branches. Every agent — whichever of the thirty-plus CLIs it happens to be running — gets its own git worktree: a real, separate directory on disk with its own checked-out files, running at the exact same moment as every other agent's. That single decision is why you can point several agents at the same problem, let them all work simultaneously instead of queued behind one shared checkout, and merge whichever result actually holds up. It's also why we built compatibility, teardown-safety, and orphan-detection infrastructure that has nothing to do with a user interface and everything to do with making that bet safe.
The Assumption Branch Switching Was Built On
Checking out a branch, working, then checking out a different branch is not a bad workflow. It's an extremely good workflow for exactly one situation: a single developer, doing one thing at a time, switching context deliberately and relatively rarely. The whole model — one working directory, one checked-out state, one set of files on disk that represents "what the repository currently looks like" — assumes there is only one actor who could possibly care what's checked out at any given moment. For most of git's history that assumption was just true. A person can only look at one file, run one test, and hold one train of thought at a time, so a single shared checkout was never really a constraint — it matched how the work actually happened.
An AI coding agent breaks that assumption the moment it exists. An agent doesn't wait for you to finish thinking before it starts; it can pick up a prompt and start editing files within seconds. And a developer running Influxx is rarely running exactly one agent — the entire point of orchestrating several CLIs side by side is that they work at the same time, not in a queue. Branch switching has no answer for "several actors need to be checked out simultaneously," because it was never asked that question.
What Breaks When Several Agents Want the Same Directory at Once
If every agent in Influxx pointed at one shared working copy, only one of them could ever be checked out at a time. That's not a performance limitation to optimize away — it's what a single working directory means. There is exactly one set of files on disk, so exactly one agent's understanding of "the current state of the repo" can be true at once.
The tempting fix is to fake parallelism: keep the agents queued, and rapidly switch which branch is checked out under whichever one is "active." It doesn't require touching git's worktree machinery at all — and it falls apart in specific, predictable ways:
- Edits leak across agents: if agent A is mid-write when agent B's turn comes up and the working copy gets checked out from under it, agent B can end up looking at a diff that partly contains A's in-progress, uncommitted edit.
- Checkouts silently destroy work: a checkout that collides with uncommitted local changes it doesn't know how to reconcile will discard them — quietly, exactly the moment you least want a background process making that call on an agent's behalf.
- Nobody's view of a file stays reliable: two agents can each be confident they know what a given file currently contains, and both be wrong, because the last write to the working directory belonged to whichever agent had it checked out most recently.
None of that is an exotic edge case. It's the direct, mechanical result of asking one mutable directory to stand in for more than one simultaneous line of work.
"People sometimes ask why we didn't just get cleverer about branch switching — snapshot the working directory before every checkout, restore it after, add enough bookkeeping to make it feel safe. We looked hard at that path, and every version of it ends the same way: you're rebuilding, in application code, the isolation git already gives you for free the moment you use a second directory. A worktree isn't a workaround we bolted on. It's git agreeing to hold two checked-out states open at the same time, which is the actual thing multi-agent orchestration needs."
— Daniel Kwon, Staff Engineer, Agent Orchestration at ETAPX
Isolation That's Structural, Not a Matter of Discipline
A worktree is a real, separate directory on disk with its own checked-out files, linked back to the same underlying repository as every other worktree created from it. When agent A is working in its worktree and agent B is working in its own, there is no step where their edits could collide — not because Influxx is careful about sequencing them, but because they are, physically, two different sets of files in two different places. Agent A writing to its copy of a file has no mechanism by which it could touch agent B's copy of that file, no matter how fast either agent is working or how many are running at once.
That distinction matters. A rule like "don't let two agents touch the working copy at once" is a policy — something that has to be enforced correctly, every time, under load. A separate directory isn't a policy. There's no shared mutable checkout left for two agents to fight over, so there's nothing left for a bug in the enforcement logic to get wrong.
The Infrastructure a Worktree-First Bet Actually Requires
None of this was a thin layer on top of ordinary git usage. Committing to "every agent gets a real worktree" as Influxx's foundational interaction model meant building infrastructure that a lighter-weight approach would never have forced us to write.
Meeting Whatever Git Is Already on the Machine
Not every developer running Influxx has the newest git installed, and we weren't willing to bake that assumption into the core interaction model. The compatibility layer underneath worktree support treats an older release — Git 2.25 — as the floor for the core workflow, and checks what a given installation actually supports before reaching for anything newer. Where a more recent release adds a worktree-related capability, Influxx uses it; where it isn't there, the core flow still has to work correctly.
Making It Safe to Tear a Worktree Down
Agents finish, get cancelled, or get abandoned mid-task, and sooner or later every one of their worktrees needs to go away. Before Influxx will tear down the terminals attached to a worktree, it checks that the worktree is actually clean. That check exists specifically so that closing an agent's session, or deleting a worktree you think you're done with, can't silently orphan real uncommitted work sitting inside it — the kind of loss you'd only discover later, when it's far more expensive to recover from.
Telling "Broken" Apart From "Dirty"
Not every worktree that needs attention is in the same condition. Some are simply dirty — real, uncommitted changes sitting in a working directory that a person or an agent needs to make an actual decision about. Others are already broken — their underlying git metadata is gone or invalid, with no meaningful state left to preserve. Treating those two situations the same way is wrong in both directions: clean up the first automatically and you risk deleting real work; refuse to clean up the second without asking and you leave dead, confusing entries lying around for no reason. Influxx's orphan-detection logic exists to tell those two cases apart before deciding what to do about either one.
"Betting the product on worktrees instead of on smarter branch switching was the easy part of this decision. The hard part was everything downstream of it. Every developer using Influxx has a slightly different git installed, on a different operating system, sometimes over SSH into a machine we've never seen. If our worktree handling assumed the newest git, or assumed a broken-looking worktree was always safe to delete, we'd just be trading one failure mode for a worse one — quietly losing someone's work instead of merely being slow about it. Believing in the architecture didn't excuse us from that engineering. If anything, it's the reason we had to do it properly."
— Priya Anand, VP of Engineering at ETAPX
Fan Out, Compare, Merge the One That Actually Worked
The payoff for all of that infrastructure is a workflow that's hard to fake with any other model: take one prompt, run it across several agents at once, and let each one work in its own isolated worktree until it's done. Because the isolation is real rather than simulated, comparing five different attempts at the same problem means comparing five real, independently checked-out states side by side — not five branches you'd have to laboriously check out one at a time, in a single shared directory, just to remember what each one actually changed.
That difference is the entire point. A comparison workflow built on branch switching would need you to check out attempt one, read it, check out attempt two, read it, and so on — holding earlier attempts in memory instead of on screen, never viewing two at once. Because every attempt already exists as its own real directory, Influxx can put them side by side as they are, and merging the winner is just merging an ordinary branch — the isolation already did its job before comparison started.
"I stopped trying to guess up front which agent would handle a gnarly refactor better and just ran three of them on the same prompt. Being able to actually look at three complete, independently checked-out versions of the change side by side — not three branches I had to check out one at a time to remember what each one did — is the part that changed how I work. I merged the one that handled an edge case I hadn't even thought to mention, and the other two just got deleted."
— Renata Silva, staff engineer at a logistics-software startup and Influxx user
Why Not Just Make Branch Switching Smarter?
It's a fair question, and we asked it of ourselves before committing to worktrees as Influxx's foundation. Branch switching was designed for a single developer's sequential attention — one person, one train of thought, switching context deliberately and relatively rarely. Multi-agent development breaks that premise immediately: several agents want to work at the exact same moment, not take turns waiting for a shared checkout to free up.
You can spend a long time making branch switching cleverer around the edges — better stashing, better safety rails, more bookkeeping to catch the failure modes above before they cause damage. We don't think that effort ends anywhere different: a model built for one actor at a time, wearing progressively more tooling to hide that fact. Worktrees are git's own native answer to a different question entirely — give each parallel actor its own real, physically separate copy of the repository. Betting Influxx's core interaction model on that answer, instead of on cleverer branch-switching automation, is what makes actual agent parallelism possible instead of a convincing simulation of it.
Frequently Asked Questions
Does running several worktrees mean storing several full copies of my repository's history?
No. A worktree shares the same underlying repository data — its commit history and refs — as every other worktree created from it. What's duplicated is each worktree's checked-out working files, not your project's entire version history. Disk cost scales with your working tree size times how many you have open at once, not your whole history multiplied.
What happens to an agent's worktree if I close Influxx before its task finishes?
The worktree and whatever it contains stay on disk exactly as the agent left them. When you come back, Influxx's orphan-detection logic tells the difference between a worktree that's genuinely broken — its git metadata gone or invalid — and one that's simply sitting there dirty with real changes in it. Only the first gets treated as safe to clean up without asking; the second waits for you to make a real decision about it.
I have an older version of git installed. Will worktree-based agents still work?
Yes. Influxx's compatibility layer treats a conservative baseline — Git 2.25 — as the floor for the core worktree workflow, and checks what a given installation actually supports rather than assuming everyone is running the newest release. Newer git versions unlock some additional convenience under the hood, but the core flow doesn't require them.
Isn't giving each agent its own branch enough, without a separate worktree?
A branch is just a name pointing at a commit — on its own, it doesn't decide which directory it gets checked out into. In a single working copy, only one branch can be checked out at a time, so giving each agent "its own branch" still leaves them taking turns for the actual checkout. A worktree is what gives each branch its own real directory to be checked out into, simultaneously with every other one.
What happens to my uncommitted changes if I delete a worktree I think I'm done with?
Influxx checks that a worktree is actually clean before it will tear down the terminals attached to it. If there's real uncommitted work still sitting in that worktree, deletion doesn't proceed silently out from under you — the whole point of that check is to make sure a cleanup action can't double as an accidental way to lose work.
Do I have to create and manage these worktrees myself?
No. Creating an isolated worktree happens automatically when you start an agent session in Influxx, and tearing it down happens as part of closing that session out. You interact with an agent as a tab in the cockpit; the underlying worktree is infrastructure you benefit from, not a workflow you have to run yourself.
Branch switching is a fine model for one person who can only do one thing at a time — it was never going to be the right model for a cockpit built to run several agents at once. Pretending otherwise would have meant shipping a product whose core promise, real parallelism, was actually careful sequencing wearing a disguise. We built the compatibility, safety, and cleanup work worktrees demanded because the alternative was betting on discipline instead of structure, and only structure holds up once enough agents are running at once.
