Claude Corner

Two Claude Sessions Fighting Over the Same Files? Start Each One in Its Own Worktree.

By ยท 29 Oct 2026

A developer seen from behind at a desk with two monitors, each showing its own column of colored blank tiles standing on the same grey base tile.

At a glance

  • Start each parallel session with claude --worktree and a name, so each one edits its own checkout on its own branch.
  • Add a .worktreeinclude file so your gitignored .env follows Claude into every new worktree.
  • Know what happens on exit, so you keep the work you want and lose only empty worktrees.

Here is an example of the problem. Claude is building a feature in one terminal when a bug report comes in. You start a second Claude session in the same folder and ask it for the fix. Ten minutes later the first session's tests fail on a file it never touched, because the second session changed it. Both sessions shared one checkout, so every edit landed in the same files. Claude Code can give each session its own copy instead.

Why it matters

A git worktree is a separate working directory with its own files and branch that shares the repository history and remote with your main checkout. While a session runs in one, Claude Code blocks file edits and commands aimed at the main checkout, and the same checks cover every subagent that session spawns. So the feature session and the bug fix session can run side by side without touching each other's files, and each ends up on a branch you can review and merge on its own. The move: whenever you open a second session on the same repo, start it in a worktree.

How to run parallel sessions in worktrees

The repository needs at least one commit. If you have never run Claude in the folder, run claude there once to accept the trust prompt first. We built these steps from Anthropic's docs and have not run them in a live session.

  1. Start the first session. Run claude --worktree feature-auth (or claude -w feature-auth). The docs say Claude Code creates .claude/worktrees/feature-auth/ at the repository root on a new branch named worktree-feature-auth and starts there.
  2. Start the second one. In another terminal, run the same command with a different name, such as claude -w fix-login. Leave out the name and Claude Code picks one for you.
  3. Keep worktrees out of git status. Add .claude/worktrees/ to your .gitignore.
  4. Bring your local secrets along. A worktree is a fresh checkout, so gitignored files like .env are missing. List them in a .worktreeinclude file at the project root, using .gitignore syntax. Only files that match a pattern and are gitignored get copied.
  5. Set up the environment. Ask Claude to install dependencies in the new worktree, or run your project's setup there yourself.
  6. Review a pull request in isolation. Run claude --worktree "#1234" with the quotes, so your shell does not read # as a comment. Claude Code fetches that pull request's head from origin into .claude/worktrees/pr-1234.
  7. On the Desktop app, turn on the Worktree button in the row under the prompt box before you start the session. Desktop uses .claude/worktrees/ by default and reads .worktreeinclude too.
claude --worktree feature-auth        # terminal 1: own folder, branch worktree-feature-auth
claude -w fix-login                   # terminal 2: separate checkout
claude --worktree "#1234"             # review PR 1234 in .claude/worktrees/pr-1234

# .gitignore
.claude/worktrees/

# .worktreeinclude (project root, .gitignore syntax)
.env
.env.local

Gotchas

  • Exit decides what survives. A clean worktree is removed with its branch when you exit. If you named the session itself, with claude -n or /rename, Claude Code asks first. If the worktree holds changes or new commits, Claude Code asks whether to keep it and prints the command to resume it later. Removing deletes that work.
  • claude -p never cleans up. Non-interactive runs have no exit prompt, so remove those worktrees yourself with git worktree remove, running git worktree unlock first if git says it is locked.
  • Shell writes are not fenced. The isolation checks read edit paths, command directories and the command text. A plain cp or shell redirect into the main checkout falls under your normal permission and sandbox settings instead.
  • One approval covers every worktree. Choosing "Yes, and don't ask again" for a Bash command in a worktree saves the rule to the main checkout's .claude/settings.local.json, where it applies across the repository. On Windows the rule stays with that worktree.

Sources:

Recommended AI prompt

Copy this paragraph into ChatGPT, Claude, Gemini, Grok, or whatever AI you use.

Prompt

I run more than one Claude Code session on the same repository and their edits keep colliding. Ask me how many sessions I usually run at once, whether I work in the terminal or the Desktop app, and which gitignored files my project needs to run. Then give me the exact commands to start each session in its own worktree, the lines for my .gitignore and .worktreeinclude, and a short cleanup routine for the end of the day. Use only behavior from the official Claude Code worktrees docs and link me to that page.