Three Ways to Run Parallel Agents in Claude Code

By a solo builder who had to figure this out the hard way

---

I am a product manager turned builder, working on an ambitious AI project. Coming from a background of managing teams, the concept of running an agent team comes naturally to me. But for a little while there, I couldn’t quite figure out how to effectively run parallel work in Claude Code. What I came to realise is that there are at least three distinct approaches for running parallel work with Claude Code. I hope this summary helps you skip the 3+ weeks I took to figure this all out.

Why Parallel Agents?

Agentic coding is accelerating my work tremendously. My most productive day was a 16-commit marathon back in February and that was with a linear one flow, taking one task at a time, executing before moving on to the next. The idea of achieving that as a solo developer, across multiple agents is exhilarating. For a long time, I’ve known that I could run parallel agents, and that I wanted to, but I couldn’t quite figure out how.

There are currently three meaningful approaches. I have tried all of them.

---

Method One: Git Worktrees (The Official Approach — and Why It Failed Me)

Git worktrees are the publicly documented, most widely discussed method for running parallel agents locally. The idea is elegant: each worktree is an isolated checkout of your repository on a different branch, allowing multiple agents to work simultaneously without stepping on each other.

In theory, this is exactly what you want. In practice, it depends enormously on the complexity of your codebase.

My setup is pretty complex: a pnpm Turborepo monorepo with over 30 workspace packages. I didn’t initially realise it, but this was a blocker to using worktrees. The biggest issue was Supabase: its local stack runs in Docker containers bound to fixed ports, making it impossible to run two instances simultaneously without manually reconfiguring everything. The problems stack up from there — each worktree needs its own full dependency install, Makerkit’s setup scripts can unpredictably modify files and leave your working tree in a dirty state, and the environment configuration files that would let you fix any of this are gitignored, so they don’t transfer at all.

Even switching branches without worktrees is painful. The running Supabase database doesn’t change with git checkout, so you’re forced to reset it and regenerate TypeScript types every time. Turborepo’s daemon conflicts across sessions and Next.js binding to a single port add further friction. The supposed convenience of worktrees ends up buried under coordination overhead that largely defeats the point.

Worktrees are the right idea. For simpler codebases, they probably work well. But for complex, service-heavy stacks, they transfer the coordination problem from your agents to your infrastructure.

---

Method Two: Claude Code Web (Remote Agents with Isolated Environments)

The failure of worktrees taught me something important: the core problem with local parallel development is shared environment. Agents conflict because they share the same ports, the same database, the same dependency tree. The solution worktrees attempt, branch isolation, does not go far enough when your stack is complex.

Claude Code Web takes a different approach. Each remote agent gets its own isolated environment. The environment conflict problem, which worktrees only partially address, is largely solved by architecture.

I tested this with a cosmetic website change. The agent made the change, committed it, and it was immediately testable on a Vercel preview branch. That workflow — agent works, commits, Vercel deploys a preview — felt super smooth.

There are still some limitations. The database situation remains a challenge: if your change requires schema updates, you need to pull the branch locally and apply migrations yourself, then push to your remote Supabase instance. Admittedly, this is a solved problem in principle; it just requires setup. I know that I can provision a Supabase instance per branch, which would make the remote agent workflow fully self-contained. There are also some security considerations to understand before integrating remote sessions into your workflow. There is also a bit of a learning curve to integrate these remote sessions into your workflow, but I would say that it is worth it.

---

Method Three: Multiple Local Sessions with Scoped Commits

My third approach is probably the simplest, it’s 100% local and the one I will probably use the most.

Claude Code allows you to run multiple sessions simultaneously, without worktrees or even branches (necessarily). But the issue was, because I was committing manually, I would finish a round of parallel agent work and face a large, undifferentiated pile of changes. I would commit them all together, writing the most descriptive commit message I could manage, but the history was muddy. It was hard to know what had come from where.

Then I noticed something in the agents’ tool calls: when I asked an agent to commit within their own sessions, they were not doing git add . instead they were staging specific files relevant to their own work. Each agent, operating in its own session, was naturally scoping its changes.

That observation unlocked the real mental model: each agent can own its commit. If you have 100 agents working in parallel, you can have 100 commits, each cleanly scoped to one piece of work. The commit becomes the unit of parallelisation. Your history is no longer and indecipherable pile, it becomes a precise, readable record of what each agent did and why.

This is the method I would recommend most immediately to anyone starting out. It requires no special infrastructure. You are working in your normal local environment, with either Claude Code Desktop or Claude Code CLI (honestly, this probably works with most other AI coding tools). It’s as simple as giving your agent the instruction: “Commit your work from this session.”

---

A Reflection

I am glad that I’ve figured out agent parallelisation and that I can share this summary with you, but I think it’s important to also share that you may have to make a mental shift in order to effectively work with parallel agents.

At Meta, I think my largest team topped out at around 10 engineers. Product managing 10 engineers was a lot, but I had a couple of engineering managers and to a significant degree the engineers could manage their own work. With agents, they can manage their execution, but they largely lack a concept of your product outside of what they are immediately executing – that still sits with you. So when you start thinking about 10 or 100 agents working in parallel, it’s exciting but also potentially overwhelming. You are the hub, as the spokes increase, so too does the context you have to hold and the information you have to navigate. Your coordination systems (be they a PRD, your Agents.md file, a coordinator agent, etc) need to be excellent, and in our rapidly developing ecosystem, constantly improving.

---

In Conclusion

All three methods are real and usable today, depending on your stack. In my opinion, multiple local sessions with scoped commits are the most accessible entry point. But Claude Code Web and worktrees are worth understanding because the world of AI does not stand still, things change every day and Anthropic or some other team may come out with something that makes one of these alternatives preferable.

If you are not yet running parallel agents in Claude Code, start. The tooling will improve. The mental model you build now, of yourself as a coordinator of parallel work rather than a sequential executor, will compound in value as it does.

---