Claude Code and git worktrees

The problem one working directory creates

Claude Code operates on the files in front of it, and a single checkout means a single state at any moment — starting a second, unrelated task means either waiting for the first to finish or switching branches mid-task and losing the first one's in-progress state. For anyone running more than one substantial Claude Code task around the same time, that's a real constraint, not a minor inconvenience: two genuinely independent pieces of work end up serialised through one shared checkout for no reason other than the checkout being singular.

What a worktree actually gives you

A git worktree is a second working directory attached to the same repository, checked out to its own branch, with its own independent files on disk — not a clone, and not a stash-and-switch, but a genuinely separate directory a Claude Code session can operate in without touching whatever's happening in any other worktree of the same repo. Two Claude Code sessions running in two worktrees of the same repository are working on the same underlying git history but cannot step on each other's uncommitted changes, because there's no shared file state between them to step on.

Where this earns its complexity

The clearest case is genuinely parallel, genuinely independent work — two unrelated bug fixes, an experimental approach you want to try without disturbing a task that's already progressing well, a long-running task you want to keep going while you start something else entirely. Each of those benefits from real isolation, not just mental bookkeeping about which branch you're supposed to be on. Work that's actually sequential — where the second task depends on the first one landing — doesn't benefit from a worktree the same way, since the dependency between them means true parallelism was never really on the table.

The failure mode this doesn't fix

Worktrees isolate file state; they don't isolate your own attention. Running several Claude Code sessions across several worktrees at once is only a net win if you can actually track what each one is doing and review each one's output properly — running four in parallel and only really paying attention to one defeats the purpose, and worse, makes it easy to approve a change in a worktree you weren't watching closely because it's sitting there finished and you want to move on. Isolation solves the file-contention problem; it does nothing for the review-attention problem, which is still yours to manage.

Cleaning up after the work is done

A worktree that's served its purpose and been merged or discarded should actually be removed, not left sitting around — an accumulation of stale worktrees pointed at branches that no longer exist or have already been merged is exactly the kind of low-grade clutter that makes it harder to tell, weeks later, which of several directories on disk is the one still worth paying attention to. Treat worktree cleanup as part of finishing the task, not a separate chore to get to eventually.

Naming worktrees so future-you can tell them apart

A worktree directory named after nothing in particular — a generic scratch folder reused across several unrelated tasks over time — defeats a good chunk of the benefit, because the isolation only helps if you can also tell at a glance which worktree is for which task weeks later. Name the directory and the branch after what the task actually is, not after "temp" or a date, so a session you return to after a break is immediately identifiable rather than requiring you to open it and reconstruct what it was for from its contents.

A lighter alternative for smaller cases

Not every parallel task needs a full worktree. If the second thing you want to do is small and quick — a fast lookup, a small unrelated fix that won't conflict with what's already in progress — a separate, disposable clone or a quick stash-and-switch can be simpler than setting up a worktree for something that'll be finished in minutes anyway. Reach for a worktree specifically when the parallel work is substantial enough that losing track of either task's state would actually cost you something.