DEV Community: Josep

Running Coding Agents in Parallel with Git Worktrees

Josep — Sun, 30 Aug 2026 21:29:33 +0000

I kept hitting the same wall with coding agents. One Claude Code or Codex session in a repo works great. The moment I wanted two tasks moving at once - login in one terminal, payments in another - they started stepping on each other. Same working directory, same checked-out branch, two processes editing the same files. Chaos.

The fix turned out to be a Git feature that has been sitting there for years: git worktree. It gives you several working directories backed by the same repository. Each folder has its own checked-out branch, but all of them share the same objects, commits and branch list.

The setup

From your main checkout:

git worktree add ../integration -b integration main
git worktree add ../feature-login -b feature/login main
git worktree add ../feature-payments -b feature/payments main

Which leaves you with something like:

project/
├── main/               → branch main
├── integration/        → branch integration
├── feature-login/      → branch feature/login
└── feature-payments/   → branch feature/payments

Now every agent gets its own folder. One terminal per worktree, one agent per terminal, and nobody touches anybody else's files:

cd feature-login    # agent 1 works here
cd feature-payments # agent 2 works here, at the same time

The part that surprised me: no push, no pull

My first instinct was: agent finishes login, pushes the branch, then I pull it into integration. That's the muscle memory from working in a team.

It's unnecessary here. All the worktrees belong to the same repository on the same machine, so Git already knows every branch locally. When agent 1 finishes:

cd feature-login
git add .
git commit -m "feat: implement login"

...the integration worktree can merge it directly:

cd ../integration
git merge feature/login
git merge feature/payments
npm test

No git push, no git pull. The directories are different, but feature/login and integration are branches of the same repo. When integration is green:

cd ../main
git merge integration

You don't even have to wait for a worktree to be deleted before merging its branch. Both folders can exist at the same time. The only thing Git refuses is having the same branch checked out in two worktrees at once - which is exactly the protection you want when agents are involved.

Cleaning up

When a feature is done, resist the rm -rf:

git worktree remove ../feature-login
git branch -d feature/login

git worktree remove deletes the folder and cleans Git's internal registry. If you already nuked the folder by hand, git worktree prune fixes the bookkeeping after the fact.

The full cycle for one task ends up being:

git worktree add ../feature-login -b feature/login main   # create
cd ../feature-login                                       # agent works, commits
cd ../integration && git merge feature/login && npm test  # integrate
git worktree remove ../feature-login                      # discard workspace
git branch -d feature/login                               # discard branch

So where does GitHub fit?

For the agents to collaborate on one machine: nowhere. Git itself is the communication mechanism.

GitHub earns its place the moment humans enter the loop - PRs, review, CI, an audit trail:

cd feature-login
git push -u origin feature/login   # open a PR from this

And if you want integration to merge exactly what's on the remote rather than the local branch:

git fetch origin
git merge origin/feature/login

I now think of it as two separate planes. Locally: worktree → commit → merge into integration → tests. Remotely: push → PR → review → CI. The second plane is for people; the first one is where the agents actually work.

The detail that sold me on the whole thing: the integration agent never copies code from the other agents, never reads their folders, doesn't even know they exist. It only knows their branch names. Git was the message bus all along.

Bonus: when every agent wants port 3000

Worktrees isolate files and branches. They don't isolate runtime. The moment two agents each run npm run dev and a Playwright suite, they all reach for :3000, the same test database, and a surprising amount of RAM per headless browser.

The workaround I use today is boring: each worktree gets its own port through an env file written at creation time, and Playwright reads it for its baseURL:

echo "PORT=3101" > ../feature-login/.env.local
echo "PORT=3102" > ../feature-payments/.env.local

But ports are only the visible part of the problem. Isolating test databases, keeping three browser suites from eating the machine, and deciding whether integration should be the only worktree allowed to run E2E at all - that deserves a post of its own. It's the next one I'm writing.

So in some cases is better to use isolated agents on VPS and i have another article that talks about that https://dev.to/servatj/the-ai-dev-environment-nobody-teaches-you-written-by-my-ai-agent-directed-by-me-p--1dg4

The AI Dev Environment Nobody Teaches You

Josep — Sun, 30 Aug 2026 11:35:36 +0000

The idea in one sentence

Don’t run Claude Code, Codex or OpenCode on your laptop. Run them on a VPS that is on 24/7 , which clones your repos, installs whatever is needed, runs, tests and reports back. You talk to it from your laptop or your phone. Your personal machine stays personal.

The setup, layer by layer

1. Machine

A Linux VPS with no desktop environment : lighter, and a backup of the OS is a backup of your entire dev environment. Windows would also work, but I don’t recommend it.
Rough sizing: 4 vCPU / 8 GB RAM is already enough to run several agent instances in parallel.
Provider: I recommend Hetzner , specifically the Server Auction section (dedicated servers other customers cancelled; somewhat older hardware but very cheap; filter by budget, e.g. up to $100/month). A fixed monthly cost instead of the per-hour billing of Codespaces and the like.
Keep the configuration reproducible so you can tear the server down and bring up an identical one tomorrow (upgrade, migration, etc.).

2. Security

Never work as root.
Firewall on, limiting which devices can connect.
Tailscale as VPN / private network: installed on the server, the laptop and the phone, so only those devices can reach the server. No exposing password-based SSH to the whole internet.
The reason is obvious: your clients’ code and credentials live in there.

3. Agents

Install the CLIs you already pay a subscription for: Claude Code, Codex, OpenCode, Kimi Code… All on subscription, not API : much cheaper and a fixed cost.
The server needs access to your GitHub to clone repos. The agents themselves install Docker, Node, Go, Python… whatever each project needs.

4. Messaging layer

An intermediary like Hermes (or OpenClaw): installed on the server and connected to your ChatGPT subscription, it takes orders via Telegram, WhatsApp, Discord or Slack. Hermes can’t use your Claude subscription directly, but it can delegate to Claude Code if it’s installed on the machine.
His personal setup: several Telegram bots pointing at the same instance. One “personal assistant” bot (email, articles, tasks) and two or more “developer” bots that know where the projects live and always delegate the actual code writing to Claude or Codex. Having two dev bots lets him launch tasks on different projects in parallel from his phone.

5. Orchestration and terminal (advanced)

Herdr : a “tmux for agents”. It opens Claude Code, Codex, etc. in one terminal and, crucially, they talk to each other : Claude can spawn a Codex instance, resume it or read its output. It has a Telegram plugin.
Direct SSH access from mobile apps: Termius , Termux (Android), a-Shell (iOS), combined with Tailscale.
VS Code over Remote SSH when you need to see the code of a large project; execution still happens on the server.

6. Planning

With several projects and sub-agents you need a tracker ( Linear, Notion , Jira…) as the single source of truth: pending, in progress, reviewed by the client, reported bugs.
The agent can read and write it via MCP ; no need to fill it in by hand. This is what I like to call the “software factory” approach, as opposed to prompt-by-prompt vibe coding.

The upsides

24/7 : a client reports a bug at night → a message from your phone → the agent fixes it.
Several projects in parallel on a single machine.
Total portability : travel with any underpowered laptop.
Agnostic : a new agent or model comes out, you install it on the server and you’re done.

The downsides

Complex projects still call for an editor to review things (solution: VS Code Remote SSH).
Port conflicts between projects on the same stack (everything wants 3000). He mentions Portless (named URLs instead of ports) as a mitigation.
E2E testing (Playwright, browsers) eats a lot of RAM and can slow down every agent at once.
Local models (he tried a DGX Spark, around $4,000): fine for landing pages and typical web apps, but they struggle with complex software; today they don’t replace cloud models.
It isn’t finished: he says himself he’s been tuning it for months and aims to have it polished by year end.

Who is it for?

Yes : if you juggle several clients or projects and ship changes daily (he works on 2–3 projects a day).
No : one project and one client; it’s overkill.
Ready-made alternatives: Cursor Cloud Agents and Claude Code on the web do the same (clone, change, open a PR), but they bill close to API prices and you don’t control the machine.

My takeaway

The interesting part isn’t “delegate to the cloud and the app builds itself”. It’s having an isolated, always-on environment you can talk to from anywhere, one that doesn’t depend on whichever agent is in fashion this month. If you work on a single project, don’t overcomplicate it. If you have several and already live between terminals, this is probably the next step.

Tools mentioned: Tailscale, Hetzner Server Auction, Portless, Herdr.