Claude + Codex in the same project with Git worktrees (2026)

Want Claude and Codex to work on one app without overwriting each other’s files? Git worktrees give each session its own checkout and branch. This follows my guide to keeping two Claude accounts on one Mac: accounts separate sign-ins; worktrees separate source folders. They solve different problems.

What a worktree separates

A worktree is another checkout linked to the same Git repository. Each checkout has its own files and branch while sharing commit history. That lets two agents edit independently. It does not separate credentials, environment variables, databases, running services or deployment targets. Treat it as a source-code workspace, not a security boundary. A branch is not an automatic release: nothing deploys until your normal delivery process does it.

Create clean starting points

Start in a Git repository with Git installed. Inspect the status and review every change. Commit only the intended shared baseline, staging explicit paths; do not blindly stage everything. Both examples start from HEAD, so uncommitted work is not copied into the new checkouts.

git status --short
git worktree add -b ai/ui ../my-app-ui HEAD
git worktree add -b ai/backend ../my-app-backend HEAD

After creating them, check the worktree list and both folders. Git shares repository history, but project setup may still be missing: dependencies, ignored files, build caches and local settings need attention in each checkout. Use approved development credentials and test data; never copy production secrets automatically. Give simultaneous servers different ports and, if both write data, separate test databases or schemas and fixture identifiers. A couple of local processes or a mock service may be enough; you do not need to containerize the whole stack.

Open the tool in the right folder

Use the Git-created UI folder for Claude Code and the backend folder for Codex. Open each as its own local project and confirm the working directory before assigning a task. This assumes both tools are already installed and signed in.

Both tools also offer managed-worktree workflows (Claude, Codex). Use those as an alternative to creating the folders manually, rather than creating a second worktree for the same task.

Agree on the interface before splitting work

Choose tasks that can progress independently. For example, Claude owns the UI branch and builds a screen plus API client; Codex owns the backend branch and implements the endpoint. Before either starts, agree on the method and path, request and response fields, authentication, validation errors and a test fixture. Keep one agent as the owner of each worktree, and assign shared files explicitly.

1. Claude · UI branch
2. Agreed API contract
3. Codex · backend branch
4. Review and integrate

Separate folders protect file edits; the agreed payload keeps both halves of the feature aligned.

A useful failure example: the UI reads items, while the endpoint returns results. Git can merge those changes without a text conflict, yet the feature still breaks. Agree on the payload before parallel work, then verify it against both implementations.

Review, integrate, then clean up

1. Inspect each diff. Review the actual changed files, configuration, migrations and data access. Run the checks that cover the agreed behavior; an agent’s completion message is not evidence.
2. Integrate one branch at a time. Bring in one reviewed branch and run its relevant checks, then integrate the second. Once both are present, test the UI against the actual endpoint.
3. Check behavior, not just Git. A clean merge does not catch mismatched fields, auth rules or assumptions about shared services. Exercise the boundary with the test fixture.

This review step is the same judgment needed when checking AI-generated app code or organizing a programmer team: clear ownership helps, but the integrated behavior still needs a human review.

Before cleanup, inspect status and recent commits in each checkout and confirm what is already integrated. List the worktrees, then remove only the completed path you intended; let Git protect uncommitted work. Do not use rm -rf or force removal as routine cleanup.

For an app nearing release, our code audit reviews architecture, critical behavior, data boundaries and release evidence in the context of your actual product scope.