Git worktrees

If you want to run Claude Code or Codex in parallel without one task overwriting another, Git worktrees are the reason that workflow works.

Git describes a worktree as another working tree attached to the same repository, which lets you check out more than one branch at a time. For coding-agent workflows, that means each agent can get its own files on disk while still sharing the same underlying Git history and refs. See the official Git worktree documentation.

Why worktrees solve the problem

A new worktree is not the same thing as copying your entire project folder.

What you get:

• A separate checkout on disk for one task or agent session.
• A separate working directory, so file edits do not collide with your main checkout.
• A clean place to run setup, tests, and app processes for that task.

What does not come along automatically:

• Untracked files.
• Gitignored local files such as .env.local.
• Dependency installs, build output, and generated artifacts.
• Running processes from your main checkout.

Claude Code documents the same behavior for .worktreeinclude: a fresh worktree does not include untracked local files unless you copy them intentionally. See Run parallel sessions with worktrees.

How agent tools use worktrees

Worktrees solve a practical coordination problem:

• One agent can change backend code while another updates frontend code.
• You can keep your usual checkout stable while an agent works elsewhere.
• Each task can have its own branch, terminal commands, and review flow.

This is why both Claude Code and Codex expose worktree workflows directly:

• Claude Code can create and manage worktrees with claude --worktree, or you can create a worktree manually with Git and start Claude inside it. See how to run Claude Code with Git worktrees.
• Codex app has a built-in Worktree mode that creates a Git worktree for a thread and lets you either keep working there or hand the thread back to Local. See how to run Codex with Git worktrees.

The branch rule that usually surprises people

Git only allows one checked-out branch per worktree at a time.

The Codex worktrees docs make this explicit: if a branch is checked out in one worktree, you cannot check out that same branch in another worktree or in your main checkout at the same time. That is why detached HEAD worktrees and handoff flows exist. See Codex worktrees.

In practice, use one of these patterns:

• Give each worktree its own branch.
• Use a detached HEAD worktree for disposable background work.
• Move work back to your main checkout before checking out the same branch there.

Why setup still needs extra work

Most worktree friction comes from local setup, not from Git itself.

If your app needs ignored local files such as .env.local, you need a repeatable way to bring them into new worktrees. In Conductor, Files to copy uses .worktreeinclude-style patterns and only copies files Git already ignores. If the workspace needs commands instead of copied files, use a setup script.

Why Conductor matters on top of worktrees

If you are happy managing raw Git worktrees yourself, Git, Claude Code, and Codex already support that workflow.

Conductor becomes useful when you want the worktree workflow plus the surrounding workspace operations:

• Create a fresh branch and worktree for each task.
• Copy allowed local files into new local workspaces.
• Run setup and run scripts per workspace.
• Keep chats, diffs, review state, and PR flow attached to the same workspace.

For the Conductor model behind that workflow, see Isolated workspaces.