Run Claude Code and Codex in parallel with Git worktrees

Choose tasks that can progress independently

Parallel work helps when the tasks have clear boundaries. One agent can inspect an API contract while another prepares a UI change against that contract. Two agents rewriting the same component before agreeing on the design usually create more integration work.

Start by naming the deliverable for each task. Include the files or area it owns, the checks that establish success and any dependency on another result. If one task cannot begin until another is done, keep that order explicit instead of starting both at once.

Example: add a filter to a project list

A concrete split might give one session the filter logic and its meaningful tests, while another session adds the controls and empty-state text. Both receive the same acceptance criteria: existing results remain visible by default, clearing the filter restores them and keyboard navigation still works.

A separate review can examine the combined result once both parts are ready. It should check whether the controls call the agreed logic and whether the test setup covers the actual behavior. This is a suggested workflow, not a measured claim that adding more agents is always faster.

Bring Claude and Codex into one shared chat

For a Claude/Codex pair, use the shared chat: start collaboration deliberately with the button or “Bring Codex in”. Both retain their own sessions and sender identities while tasks, replies and images appear in one visible timeline.

Use Together to let the lead coordinate, or address Claude or Codex directly. With a repository attached, the partner has its own worktree. Continue to plan integration and checks on the combined result.

A shared conversation is not proof that checks passed. End collaboration when no further handoffs are wanted. After a restart, it needs a deliberate start; interrupted handoffs can require attention. The detailed documentation explains recovery and error cases.

Keep conversations and working files separate

A session isolates its conversation. A Git worktree isolates a checked-out working directory on a branch. When you attach a repository or create workers through IXIOM's team workflow, use that assigned checkout consistently so one worker does not overwrite another worker's files.

Worktrees still share repository history. They do not resolve conflicting designs, shared databases or external deployments. Give each task an explicit rule for those shared resources. Two different directories are not permission for two agents to deploy the same service simultaneously.

Move from assignment to an integrated result

IXIOM's Teams workflow makes the handoff visible. The lead holds the integration context, workers produce bounded changes and the guardian reviews the result against the repository's standards. Review findings can send work back for another round.

1. Write a shared brief

   Describe the requested behavior, the constraints and the required checks. Review the proposed task split before opening the workers.

2. Give each editing worker its assigned checkout

   Keep its changes on the assigned branch and in that worktree. For independent read-only research, a separate editing branch may not be necessary.

3. Review the completed changes

   Inspect the diff and test results. Treat unresolved guardian findings as work to assess, even if the configured review-round limit has been reached.

4. Integrate and verify the combined behavior

   Merge the accepted results through the lead's integration workflow. Run the required checks on the combined result; two independently passing branches can still conflict when merged.

5. Verify delivery

   Use the repository's documented release process and confirm the running version or resulting behavior. A successful push alone does not show that a deployment has finished.

Mix backends without losing the project context

Use Claude Code, Codex, Antigravity, Kimi, Grok, Hermes or supported ACP agents in their own sessions. The shared chat currently connects Claude and Codex. Choose a configured backend appropriate to each task. Provider limits and any API costs still apply.

Keep the accepted decisions in the repository brief or project documentation rather than assuming another conversation has seen them. A short written interface agreement is often more useful than asking every agent to infer the same design separately.

Keep the workload understandable

Begin with a small number of workers. Use descriptive names, check the board for blocked work and bring dependent results together deliberately. Increase parallelism only when you can still explain what each session owns.

For the full role descriptions, task board and integration settings, open the Teams walkthrough. For general session controls and layouts, use the documentation. The result you want is a checked, integrated change that you can understand and maintain.