Git Worktree Command Builder

Why worktrees are the secret to parallel Claude Code

A git worktree lets you check out more than one branch of the same repository at the same time, each in its own folder, all sharing a single underlying git database. That sounds like a niche feature until you start running Claude Code. The moment you want two agents working at once - one building a feature while another fixes a bug - you hit a wall: two agents in the same folder step on each other's files. Worktrees remove that wall. Each agent gets its own folder and its own branch, and none of them collide.

This builder generates the exact git worktree commands for adding, listing, and removing worktrees. Fill in a branch and a folder, and copy the command. Everything is generated in your browser - nothing is sent anywhere.

The parallel-agent pattern in practice

1. From your main repo, create one worktree per task: git worktree add -b agent-1 ../repo-agent-1 main, then agent-2, and so on.
2. Open a separate terminal in each worktree folder and start a Claude Code session there. Each session sees only its own branch.
3. Let the agents run in parallel. Because they are on different branches in different folders, their edits never overwrite each other.
4. When an agent finishes, review its branch, then merge it back into main like any normal branch.
5. Remove the finished worktree with git worktree remove ../repo-agent-1 to keep things tidy.

Add, list, remove - the three commands you need

• git worktree add -b <branch> <path> <base> - create a new branch in a new folder. The most common command for spinning up an agent.
• git worktree add <path> <existing-branch> - check out a branch that already exists into a new folder.
• git worktree list - see every worktree, its folder, and its branch. Your map of what is running where.
• git worktree remove <path> - tear down a worktree once its branch is merged. Fails safely if there is uncommitted work.
• git worktree prune - clean up references for folders you deleted by hand. Harmless housekeeping.

Where to put worktree folders

Put worktree folders as siblings of your main repo, not inside it. If you nest a worktree inside your primary checkout, git and your editor can get confused, and tools that scan the tree may double-count files. A clean layout is a parent folder that holds the main repo and each agent worktree side by side: repo, repo-agent-1, repo-agent-2. That way each folder is a self-contained working copy and nothing overlaps.

Cleaning up safely

The one thing to watch is uncommitted work. git worktree remove refuses to delete a worktree that has uncommitted changes, which is a helpful guardrail. If you add --force it will delete anyway, and that work is gone. So the safe habit is: before removing a worktree, cd into it, run git status, and commit or stash anything you want to keep. If you deleted a worktree folder manually with rm, run git worktree prune afterward so git forgets the stale reference.

Worktrees vs clones

You could get parallelism by cloning the repo several times, but worktrees are lighter and safer. A clone duplicates the entire git history on disk and drifts out of sync with your other copies. Worktrees share one history, so a commit you make in one is instantly visible to the others via git. Less disk, less drift, one source of truth. For running several Claude Code agents against the same project, worktrees are almost always the right tool.