Use Claude Code and Codex together on the same codebase

You will finish with two coding agents, one running in each worktree, able to hand off work without losing context and with clear review boundaries before changes reach the main branch.

Set up separate worktrees for each agent

Claude Code and Codex must not share the same working directory. Create two worktrees, one for each agent, so their changes stay isolated and can be reviewed independently before merging.

Start from the main branch and create a worktree for the first agent. Repeat for the second agent using a different path. This keeps each agent’s session context contained to its own copy of the code.

git worktree add ../worktree-claude main

# In a new terminal:
cd ../worktree-claude

# For the second agent:
git worktree add ../worktree-codex main

cd ../worktree-codex

Open each worktree in its own editor instance or terminal. Run each agent from the matching directory so its session and file cache stay scoped to that worktree.

Record ownership and assumptions before switching agents

Each agent starts with a blank session. Before you hand off work you must capture what has been done, why it was done, and who owns the next step. Do this in a shared place both agents can read and write.

Create a lightweight work log in the root of each worktree. Include the current task, decisions made, assumptions validated, and the next owner. Update it every time you switch agents so the new agent begins with full context.

# worktree-claude/WORKLOG.md
Task: Add user authentication middleware
Decisions:
- Chose JWT over sessions for stateless auth
- Placed middleware before route handlers
Assumptions:
- Auth service is already deployed
- Client SDK supports JWT refresh
Next owner: Codex agent

# worktree-codex/WORKLOG.md
Task: Add user authentication middleware
Decisions:
- Chose JWT over sessions for stateless auth
- Placed middleware before route handlers
Assumptions:
- Auth service is already deployed
- Client SDK supports JWT refresh
Next owner: Reviewer

If you already use a shared workspace like a local MCP server, record the same fields there instead. The goal is to have a single source of truth for task state that both agents can read and append to.

Hand off work by transferring state and ownership

When you move from one agent to another, transfer the work log entry and any related artifacts such as test results or review comments. The new agent should start from the recorded state rather than from scratch.

In the receiving worktree, load the work log and verify that the assumptions still hold. If they do not, the new agent can update them immediately instead of discovering them later during review.

If you use a local MCP server, register the new agent’s presence and claim the task with a call to the appropriate tool. This surfaces any overlapping work before edits begin.

# Example using a local MCP server
start_work(task_id="auth-middleware", agent_name="codex-agent", scope="../worktree-codex")

After the transfer, the new agent can continue where the previous one left off. Its session is scoped to the new worktree, so it does not inherit unrelated files or prior prompts.

Review cross-tool changes before they reach main

Each agent produces changes in isolation, so you must review the union of both sets of edits before merging. Use a temporary branch to gather both worktrees’ changes, then open a pull request against main.

In the PR, check for conflicts between the two agents’ edits and for violations of the shared assumptions. If an assumption no longer holds, update it in the work log and include that update in the PR as well.

Require approvals from reviewers who understand both sets of changes. The reviewers should verify that the merged result matches the recorded decisions and that no step was accidentally undone.

If you use a local MCP server, you can inspect the work state across both agents before the PR. This shows what each agent intended, what it decided, and what it added to the work log.

# Inspect both agents’ work states before the PR
inspect_work(task_id="auth-middleware", scope="../worktree-claude")

inspect_work(task_id="auth-middleware", scope="../worktree-codex")

Only after the PR is approved and merged should you delete the worktrees. This keeps the main branch clean and avoids merge conflicts from overlapping sessions.

What happens if you skip the work log

Without a shared record, each agent starts with no knowledge of the other’s decisions. One may revert the other’s changes, duplicate work, or make assumptions that no longer hold, leading to extra review cycles and potential bugs.

What happens if the worktrees are not separate

What to do when the agents step on each other

If one agent undoes the other’s changes, the first step is to confirm that both agents were working from the same state. Use the work log to see which decisions each agent inherited.

If the log shows a mismatch, correct the assumption in the log and re-run the affected agent with the updated context. If the log is correct but the edits still conflict, split the next task so each agent works on a distinct part of the codebase.

For recurring overlap, consider assigning each agent a narrow slice of the codebase or a specific concern such as security or performance, so their scopes do not intersect.

If you want a more automated way to surface overlaps before edits happen, register each agent’s presence with a shared MCP server. Overlap warnings arrive when an agent claims work, which the five tools each contribute to in a different way.

When to use a shared workspace

A shared workspace is useful when you run more than two agents or when the tasks span multiple repositories. It keeps the work log, decisions, and ownership in one place that all agents can read and write.

If you only need to coordinate two agents on a single repository, simple worktrees and a work log are enough. The workspace becomes helpful when the situation grows in complexity.

What about Concord AI

Concord AI provides a local MCP server and CLI that coding agents call while they work. It surfaces presence, task memory, ownership, agent-to-agent messaging, and review evidence in one shared workspace, which makes the workflow we described here automatic.

If you prefer to run agents without managing worktrees and logs yourself, Concord’s tools can handle the coordination for you. The rest of this post focuses on the manual approach so you understand what the tools do under the hood.