Use Claude and Codex with a clear handover

Using two coding agents is useful when each has a clear job. It becomes confusing when both edit the same files, neither knows which result was tested and the handover consists of a pasted conversation.

By July 2026, my project work included mobile smoke checks for public routes. That gives a second agent something more useful than an opinion to work with: a repeatable check and a specific behaviour to challenge.

Choose the split before opening the second session

One practical arrangement is to let Claude implement a focused change and ask Codex to review the diff and test assumptions. Swap those roles when it suits the task. I would not turn that into a permanent claim that one vendor is always the builder and the other always the reviewer.

The reviewer should begin with a clear instruction to inspect and report. If you later want it to fix an issue, explicitly transfer ownership of that work. Two independent editors in the same checkout can overwrite a change or test a moving target.

Use separate working directories for separate edits

Git worktrees let branches have their own working directories. They are an ordinary Git feature, so this workflow does not depend on a particular agent having a built-in worktree interface.

git worktree add ../project-agent-review -b review/agent-change

Run that from the intended repository after checking its state. A new worktree starts from a commit; it does not automatically include the uncommitted edits in your original directory. Commit the scoped work or deliberately transfer a reviewed patch before asking the reviewer to assess it. Keep unrelated changes out.

Pass a small evidence packet

Objective: what the user should now be able to do.
Scope: repository, branch and relevant files.
Current state: commit or patch being reviewed.
Checks: commands run and observed results.
Uncertainty: what remains untested.
Next action: review only, or the specific authorised fix.

This is enough to orient a fresh session without requiring it to trust a summary of every earlier message. Include the actual failing case if one exists. If a mobile check passes but keyboard use has not been tested, name that gap.

Ask the reviewer to look for a way it fails

“Does this look good?” invites a broad impression. “Check whether the menu remains usable with keyboard focus and at a narrow viewport” gives the reviewer an observable task. Ask for findings tied to code and behaviour, with enough detail to reproduce them.

Agreement between two models is not proof. Both can share the same mistaken assumption. A second agent earns its place by finding a missing case, checking an independent source or running a relevant test.

Keep one owner for integration and deployment. Bring the changes together, resolve conflicts and run the checks on the combined result. Then report what was reviewed separately from what was tested and what reached the live site.