Claude Code and Codex in Parallel: git worktree and .worktreeinclude

If you run Claude Code and Codex on the same repository at the same time, use git worktree to give each AI its own working directory and branch. For Codex, create a worktree with git worktree add and pass it with codex --cd. For Claude Code, let claude --worktree create its own.

Checked: 2026-10-31. Versions: Claude Code 2.1.312 / Codex CLI 0.163.0 / Git 2.56.0.

Key points: use a separate directory and branch per task. Configure copying of gitignored, untracked files separately. Handle ports, databases, and permissions independently.

#What happens when two AIs work in the same folder?

A working directory has only one checked-out branch (HEAD) and one set of files. If one AI successfully runs git switch, the files the other AI is editing change too, and uncommitted changes from both end up in the same place. git worktree adds working directories to a repository, and each one has its own HEAD and files.

We tested this with Git commands in a fixture repository that has no origin. Edits made in the added worktree did not show up in the original working directory. Both directories share one common Git directory, so branches and commits are shared. Git refused to check out a branch in a second worktree while another worktree had it checked out. Gitignored files were not present in the added worktree. We also ran a deliberately broken procedure that pointed both workspaces at the same path, and the check caught it.

#How the three approaches differ

#Steps

The commands below are a practical example. In this test we ran only the Git isolation checks and claude -p --worktree. We did not run codex --cd; that part is based on its help output and the Codex CLI reference.

cd /path/to/repo
git status --short
git worktree add -b codex-task ../repo-codex HEAD

A worktree created from HEAD does not include uncommitted changes. If git status --short lists changes, commit them first or decide to keep them in the original location. Then open another terminal and start Codex from the original repository directory. The --cd option sets the working directory.

cd /path/to/repo
codex --cd ../repo-codex

For a shared starting commit, first add worktree.baseRef: "head" to project settings as shown under “Choosing the base branch.” Otherwise Claude normally starts from the remote default branch when origin is configured, while the Codex worktree above starts from HEAD. For a first interactive run in a directory, first run claude and accept workspace trust.

In the original terminal, start Claude Code in its own worktree.

claude --worktree claude-task

The codex exec article explains how to run Codex non-interactively. The instruction discovery article explains which instruction files Claude Code reads.

#What does claude -w create?

According to the official docs, Claude Code creates the workspace under .claude/worktrees/<name>/ at the repository root and checks out a new branch named worktree-<name>. If you omit the name, it generates one. The docs also recommend adding .claude/worktrees/ to .gitignore. Interactive runs require workspace trust, and runs with -p skip that check.

In our test, claude -p --worktree with-include created the workspace and branch following those rules. git worktree list showed the worktree locked by a Claude session. The run then printed a not-logged-in message and exited with code 1, so no model answer was produced. In a repository with no commits, it printed Failed to resolve base branch "HEAD" and failed before creating the worktree. We did not verify interactive startup, cleanup on exit, or two models actually working in parallel.

#Choosing the base branch

In the official spec, new worktrees branch from the remote default branch by default (usually main). If no remote is configured, or origin/HEAD cannot be fetched, they branch from the current HEAD. Our fixture has no origin, so the only behavior we confirmed is branching from the current HEAD. To branch from work in progress, set worktree.baseRef to "head". The example below shows how this would look in the project settings file .claude/settings.json. It is for illustration only; we did not use this setting in the test.

{
  "worktree": {
    "baseRef": "head"
  }
}

#Are .env and node_modules copied?

Git does not copy them if they are gitignored and untracked. In the official spec, the normal Git-based Claude Code creation path copies only files that match a pattern in .worktreeinclude and are also gitignored. We tested this with local-fixture.txt, which contains only a harmless string. Without .worktreeinclude the file was not copied; with it, the file was copied. We did not copy the real values of any secret .env file.

.gitignore example:

.claude/worktrees/
local-fixture.txt

.worktreeinclude example:

local-fixture.txt

A custom WorktreeCreate hook replaces this copy behavior. We did not test the hook path.

List only the file names you need in the patterns. If you include .env, every new worktree becomes another place that holds your secrets. Install node_modules in each worktree, and configure ports and databases for each worktree as well. Separate workspaces do not guarantee separate execution permissions or secrets.

#When should you clean up?

Clean up after you have committed and merged the results, or saved them somewhere else. Before that, check for uncommitted changes. If the worktree branched from main, also check for commits that have not been merged yet.

git worktree list
git -C ../repo-codex status --short
git -C ../repo-codex diff
git log --oneline main..codex-task

In the official spec, when you exit an interactive session, Claude checks the worktree for changes and new commits. It may remove a clean worktree automatically, and it asks whether to keep or remove one that has work in it. We did not verify this. The docs say -p has no exit prompt and leaves the worktree and creation lock in place. A later stale-lock sweep may release that lock. Our run also left the lock in place. Follow the official docs for removal steps.

#FAQ

#If I switch branches in the same folder, does it affect other sessions?

Yes. The HEAD and files of a working directory are shared by every session running in it. Separate worktrees give each session its own HEAD and files, but branches and commits are still shared.

#Will edits from Claude and Codex collide?

If they work in separate worktrees, edits in one do not appear in the other's working directory (measured with Git). Merge conflicts can still happen when you combine their work. We did not verify running both models at the same time.

#What does claude -w create?

It creates a workspace at .claude/worktrees/<name>/ and a branch named worktree-<name>. Our -p run also created them, but it exited with code 1 because we were not logged in.

#Are .env and node_modules copied?

Git does not copy them if they are gitignored and untracked. The normal Git-based Claude Code creation path copies only files that match .worktreeinclude and are also gitignored. Install node_modules in each worktree.

#When should I clean up?

After you have merged or saved the results. Before that, check what remains with git worktree list, status, and diff. -p does not clean up the worktree on exit; our run still had a lock immediately afterward.