Three jobs at once, zero mess

What it is and why it matters

If you open three Claude Code sessions in the same folder and give each one a different job, sooner or later they step on each other's toes. One changes a file while another is working on it, and in the end you can't tell which change came from whom.

A worktree solves exactly this. It's a copy of the project in its own folder, with its own branch. The project's history is shared, because this is a git feature and not a Claude trick, but the files are separate: what Claude changes in one copy doesn't touch the others.

Each Claude session works in its own copy: nobody touches the main project until you decide. At the end you look at what each one did, keep what works and throw away the rest.

You only need one thing: the project has to use git and have at least one commit.

1. One session, one copy

From the terminal, open each session already inside its own copy. From the project folder, run:

claude --worktree login-bug

The short version, -w login-bug, works too. Claude Code creates the folder .claude/worktrees/login-bug on a new branch, worktree-login-bug, and the session works inside it.

Inside a session that's already open

If the session is already open, or you don't use the terminal, write this as the very first thing:

Work in a new worktree called login-bug.

Claude creates the copy by itself and tells you where it's working. In the desktop app you can also pick the worktree option when you start a new session.

Repeat in other windows with other names: “pricing-page”, “tests”. One job per session, with a clear name: two hours from now you need to know at a glance what's inside each copy.

One thing to do just once: add .claude/worktrees/ to the .gitignore file, so the copies don't show up as new files in the main project. You can ask Claude to do it in one line.

2. What to know before you start

The copy starts from the main branch online, usually main, not from what you have on your computer and haven't uploaded yet. If you have commits you haven't pushed yet, they aren't in the copy: push first, then open the copies. If the project isn't online anywhere, the copy starts from where you are.

Then there are the files. A copy only contains the files git knows about: it doesn't bring along files excluded from the project, like .env with the keys, or the installed libraries. If you start without them, the app in the copy won't launch, or the tests fail for reasons that have nothing to do with the job.

To have .env in every copy, create a .worktreeinclude file in the project's main folder with one line in it:

.env

Claude Code reads it every time it creates a copy and copies the listed files into it. It follows the same rules as .gitignore and only copies files that git ignores, so it never duplicates any of the code. If you have other files like that, such as .env.local, add one line for each.

The libraries, on the other hand, need to be installed. In the copy, ask:

Install what's needed in this copy.

3. When it's done: save and check

Save first. A merge only sees work saved with a commit: whatever only sits in the copy's folder doesn't come across. In the copy's session, write:

Commit all the work in this copy.

Then switch to the main session, the one open in the real project, and write:

Show me what the worktree-login-bug branch changes compared to main, file by file, and run the tests.

If the list shows a file that has nothing to do with the job, like the pricing page in a login job, ask Claude why it touched it.

4. Merge what works

Still from the main session:

Merge the worktree-login-bug branch into main. If there are conflicts, stop and explain them to me before deciding.

If your project's main branch isn't called main, say it's master, change the name in the prompt. If you're not sure, ask Claude.

A conflict is when two jobs changed the same lines in different ways and someone has to choose which version to keep. I'd rather understand what Claude is choosing than find out later.

One at a time: first one, tests, then the next. If you merge three branches in a row and then something breaks, you don't know which of the three did it.

5. Throw away what doesn't

When you close a session that works in a copy, Claude Code checks whether there's any work inside: changed files, new files, commits. If there is, it asks whether to keep the copy or remove it. If the copy is clean and you haven't named the session, it removes it by itself.

If you don't like the work, remove it: the main project stays as it was. But removing the copy deletes the folder and its branch, with everything in them. If you've already merged the work, you lose nothing, because it's already in the main branch.

If you like, before removing it, ask:

Summarize what you tried in this copy

That way the idea isn't lost. If you decide to keep the copy instead, Claude Code prints the command to pick it up again later when you exit.

To see how many copies you have lying around, ask Claude or run git worktree list. To remove one by hand, there's git worktree remove, followed by the copy's folder.

The golden rule

Three different jobs, three copies. If two jobs touch the same files, do them one after the other: copies prevent disasters, not conflicts.

The login bug and the pricing page work fine in parallel, because they live in different parts of the app. Redoing the menu and changing the colors of the whole app don't: they end up in the same files, and when you merge you find them all in conflict.

Common mistakes

• Two jobs that touch the same files in two copies: split them by area of the app, or do them one after the other.
• Starting without .env and without libraries: have the copy set up before you hand over the job, or put the files in .worktreeinclude.
• Merging without a commit: what only sits in the folder doesn't travel with the branch, so have the commit made in the copy first.
• Merging everything at once: merge one branch, run the tests, then move on to the next.
• Removing a copy without looking at it: removing also deletes the branch, so merge first or get a summary of what was inside.

Checklist

• The project uses git and has at least one commit
• .claude/worktrees/ is in .gitignore
• One session per job, each in its own copy with a clear name
• Every copy has .env and libraries before it starts
• Commit in the copy, then review from the main session
• One branch at a time, with tests in between
• Copies you no longer need are removed

Frequently asked questions