Claude Code Parallel Sessions: Running Multiple Agents with Git Worktrees

Yesterday I merged 17 PRs, closed 22 issues, and still have 7 pending. Our sprint ends tonight. I didn't write most of the code. I ran Claude Code parallel sessions across three terminals, reviewed what the agents produced, and merged what was ready.

This isn't theoretical. I'm going to walk through exactly what I did, what the setup looks like, and why the hardest part has nothing to do with git.

The Setup: Issues as Fuel

Before you can run parallel agents, you need a backlog of well-scoped tasks. For us, that's GitHub Issues inside a GitHub Project board.

Anyone on the team can file an issue. We have a flow where Claude knows how to create GitHub issues that are easy to pick up later: clear title, reproduction steps for bugs, acceptance criteria for features. There's a triage command that classifies them by priority (P0, P1, P2) and size. By the time I sit down to work, the sprint board already has everything sorted.

Yesterday, I wanted to clear all P0 issues from the current sprint. Some were small bugs. Some were bigger features. Each one already had enough context in the issue for an agent to work on it independently.

That last sentence is the whole game. If your issues aren't spec'd well enough for an agent to pick up cold, parallel sessions won't save you. You'll spend more time explaining context than you save in implementation.

Three Terminals, Three Roles

I use CMUX to manage multiple Claude Code sessions side by side. Here's how yesterday looked:

Terminal 1: A Claude Code session in its own git worktree, dedicated to a single GitHub issue. I tell Claude to create a worktree and a branch for issue #47 (or whatever the number is). It checks out a clean copy of the repo, creates a branch like fix/47-broken-validation, and starts working. Fully isolated from everything else.

Terminal 2: Same thing, different issue. Another worktree, another branch, another agent working independently. While Terminal 1 is fixing a validation bug, Terminal 2 is implementing a small feature from a different part of the codebase.

Terminal 3: This one stays on the main repo. No worktree. This is where I live. I review the PRs that the other two terminals create, run the app, test the changes, run a code review, and merge what's ready. When a PR gets merged, I pull the next P0 issue from the board and send one of the free terminals on it.

The cycle runs all day. Two agents build, I review and merge, then reassign. By the end of the day: 17 merged, 22 closed, 7 still pending review.

I go deeper on parallel sessions and worktree-based isolation in the agentic coding course.

Why Worktrees and Not Separate Clones

A git worktree is a lightweight checkout of a different branch that shares the same .git directory as your main repo. Not a clone. Not a copy. Same history, same remotes, same config.

git worktree add ../fix-47 -b fix/47-broken-validation

Claude Code has built-in worktree support. You can also use the --worktree flag to start a session directly in a new worktree.

The important thing: your CLAUDE.md and .claude/ directory live in the git history. Every worktree inherits the same project context automatically. Each agent reads the same conventions, the same boundary rules, the same architecture docs. You don't re-explain your codebase three times.

Context Switching Will Break Your Brain

Here's what nobody tells you about running Claude Code parallel sessions: the tooling is trivial. CMUX, worktrees, issue boards. You can set all of that up in an afternoon.

The hard part is your brain.

When Terminal 1 asks you a question about auth middleware while Terminal 2 is waiting for approval on a database migration and Terminal 3 has a failing test you need to look at, your head starts spinning. You lose track of which terminal is working on what. You approve something you shouldn't have. You forget which PR you already reviewed.

It feels like you're losing your mind. That's normal. That's the learning curve.

My advice: start with two terminals, not three. One agent works, you review in the other. Get comfortable with the rhythm. Learn to context-switch without losing track of what each session is doing.

Give yourself permission to be slow at first. You're training a new skill. Not a technical skill. A cognitive one. The ability to hold multiple independent streams of work in your head, switch between them without confusion, and maintain review quality across all of them.

After a few weeks of two terminals, add a third. That's when the real leverage kicks in, because now you have a dedicated review terminal and two parallel agents producing work for you to check.

What Makes It Work (and What Breaks It)

The system works when:

• Issues are well-scoped. One issue, one concern, enough context for an agent to work autonomously.
• Tasks don't touch the same files. Two agents editing the same config file means merge conflicts that eat more time than you saved.
• You actually review. Skip the review step and you're not doing agentic coding. You're just shipping whatever came out.

The system breaks when:

• Issues are vague. "Fix the dashboard" is not an issue an agent can pick up. "The revenue chart shows NaN when the date range is empty" is.
• You try to go too fast. Four or five simultaneous agents sounds great until the merge queue piles up and rebases start conflicting.
• You stop paying attention. Agents will confidently tell you everything works when the code compiles but tests fail. Trust your tests, not the agent's self-report.

Three terminals is my sweet spot. Two is always safe. Beyond three, the cognitive load and merge overhead start eating into the gains.

The Numbers

17 PRs merged. 22 issues closed. 7 pending. One day of work on a sprint that ends tonight.

I didn't type most of the code. I reviewed it, tested it, fixed what needed fixing, and merged what was ready. The role shift is the real insight here. You stop being the person who writes code and start being the person who directs and validates work. Like a tech lead, except your team is three Claude Code sessions in CMUX panes.

That shift is uncomfortable at first. Then it becomes the only way you want to work.

Yesterday changed how I think about sprints. Not more hours, better decomposition. I cover scaling up in the agentic coding course.