Lately I’ve been running multiple Claude agents in parallel using claude agents mode. The thing that made it click was worktrees. I want to lay out the benefits of this workflow and note what worked and what didn’t, so the next iteration is easier.
Claude Code has a built-in EnterWorktree tool. It spins up a new worktree inside the current directory’s .claude folder and moves my working directory into it. For a single session that works well. Once I’m working on several tasks at once, I need a new terminal window per task, and I have to flip between each to check progress and approve changes.
Claude agents mode fixes the window problem. I monitor independent sessions and switch between them inside one terminal. No more four terminals. No more guessing which task is done or waiting on review. That alone was a nice upgrade.
Once I had agents mode, I wanted to isolate each agent’s task so I could run several in one repo and still search a second repo for context while I worked. The classic case is a frontend that depends on a separate backend.
Here the built-in worktree tool fought me. The moment an agent enters a worktree, its working directory moves into that subdirectory. It loses easy sight of everything else.
The Skill
begin-worktree creates the worktree wherever I point it. It auto-installs node modules so the tree is actually runnable, makes sure the worktree is tracking the correct git origin, and keeps the agent’s working directory where agents mode was initialized. The agent does its work isolated from other in-flight tasks. It still holds context over the backend repo and the up-to-date main checkout.
For a while I couldn’t explain why this felt better than the default. The wins I kept listing were:
- less stashing
- better commit timing
- not accidentally picking up another agent’s work
The underlying theme is that every unit of work has a stable home that doesn’t move when my attention moves.
With a single checkout, the repo holds one state at a time. Whatever I touched last. To switch tasks cleanly I commit what’s there first, and that forces a commit before the work is ready. A premature commit is one more thing to review and untangle later. Worktrees mean I never switch branches at all. Each task keeps its own staged changes, unstaged changes, and commits, right where the agent left them. I point the agent back at its worktree and it picks up exactly where it stopped. That’s the real velocity gain. It’s not a git trick. I skip the untimely commit and the cleanup it creates.
Here’s the trade I danced around for a while. The default moves me into the worktree, so I physically can’t touch main. Isolation comes free, context costs a step. My skill flips it. The agent stays in the parent, so context is free and isolation is now the thing I have to enforce. Every edit, install, and test run has to route to the worktree path, not the main checkout sitting right next to it. The skill enforces what used to be automatic. For one person running long features across repos, I think that trade is worth it.
The payoff is that I can work on long-running features without switching branches. Less stashing, cleaner commit timing, no cross-contamination. The main repository stays on origin for up-to-date code research by both me and Claude. That last bit is a quietly good context addition during development, and especially when chasing an active bug.
It’s a simple change with a lot of context benefit. It makes monitoring many sessions much simpler. I’ve heard there are other tools with similar setups. I enjoy rolling my own skills tailored to my setup, and building it is partly how I understand it.
A Couple Things to Watch
Worth flagging for anyone trying this. Worktrees isolate files and branches. They do not isolate ports or databases. Two agents running the app against localhost:3000 or the same dev DB will step on each other, even with their code fully separated. Most dev servers auto-bump to the next free port, so the port half usually sorts itself out. The shared database is the one to watch.
Worktrees also accumulate. A fresh one per task is great until I have a graveyard of stale ones, and letting agents create them makes that worse, so pruning has to be part of the routine. A reference checkout only stays up to date if something actually pulls. One that’s drifted is just a confidently stale one.
I can’t fully prove the velocity gain. It’s anecdotal, but real enough that I keep building on it. The short version: context-by-default isolation for a solo orchestrator. The clearest win so far is never committing before the work is ready. I suspect there’s more, and I’ll know as I keep running it.
Running agents in parallel is only half the problem. The other half is what happens to all that code once it lands. Four agents producing four PRs drops four reviews on one person at once, and review doesn’t parallelize. So the next thing on my mind is a feature-development harness that reviews and tests each agent’s work before it reaches me. That’s a bigger topic, so it’s getting its own post.