How does Orca run Codex and Claude Code in parallel: Worktree, task comparison and mobile approval

Use Orca to put Codex and Claude Code into independent Git worktrees for parallel execution, compare diffs, tests, and risks; receive completion notifications, send follow-up questions, and retain manual merge approval through the mobile companion app.

If the same bug or function is given to Codex and Claude Code each, blind spots will often be discovered faster than letting an Agent retry infinitely. But what is really difficult is controlling the process: two changes cannot cover each other, the results must be comparable, and people must be able to know when the task is completed and whether they should continue when they leave the computer. Orca runs multiple terminal agents in independent Git worktrees and tracks sessions, diffs, and task status in the same place. Orca official warehouse

This article focuses on “compare before approval”: parallel running is not an automatic merge; the mobile version is not a substitute for code review, but allows you to check the progress in time, send follow-up questions and decide which results are worthy of returning to the computer for careful review.

Establish the correct boundary first: parallel execution does not mean automatic adoption

Orca can run Codex, Claude Code, and other terminal agents side by side, with each agent using its own Git worktree. The official README works by assigning the same prompt to multiple Agents, comparing the results after completion in the isolated work tree, and then merging the winning solution.

Therefore, the entire process should be divided into three layers:

Stage Who completes Product
Execution Codex / Claude Code Independent branch, diff, test output, description
Comparison Orca + manual review Plan differences, risk points, candidate conclusions
Approval and merge Manual Accepted commits, necessary additional modifications

Don’t take “both Agents say it’s done” as approval. Especially permissions, database migrations, dependency upgrades and deleted files must be reviewed before merging the actual diff.

How to split tasks so that comparison is meaningful

If two agents receive a completely vague “fix login problem”, they often end up with two large changes that cannot be compared horizontally. A unified acceptance baseline should be given to each task, and the strategies should be different:

1
2
3
4
共同条件:复现登录 token 过期后的重试失败;必须通过现有登录测试;不改 API 协议。

Codex:从请求重试链路定位根因,提交最小修复,并说明为何不会影响刷新逻辑。
Claude Code:先写失败复现与回归测试,再提出最小修复;不改无关认证模块。

Only look at four questions when comparing:

  1. Which solution actually reproduces and covers the problem?
  2. Which diff is smaller and has clearer boundaries?
  3. Which test command was actually run and was the output reproducible?
  4. Which solution introduces lower risks of dependencies, permissions, or regressions?

This way the difference between Codex and Claude Code becomes a measurable engineering choice, rather than a comparison of who wrote the instructions more convincingly.

Worktree prevents two candidate changes from contaminating each other

Git worktree allows different branches of the same repository to have different working directories. Orca runs the Agent in each isolated work tree, so A’s formatting, dependency installation, or file deletion does not directly change to B’s directory, nor directly pollute your home directory.

It is still recommended to tidy up the main workspace before starting:

1
2
3
4
git status
git fetch --all --prune
git switch main
git pull --ff-only

Then use human-readable branch names for the candidates:

1
2
3
agent/login-fix-codex
agent/login-fix-claude
agent/login-tests

Isolation does not eliminate merge conflicts: if two schemes end up modifying the same certification file, the merge still requires selecting one master scheme, or picking independent test commits from the other scheme. Do not merge multiple candidate branches into main at once.

Practical sequence for starting two Agents in Orca

The specific buttons change with the version, but the following order will not change:

  1. Open the Git repository in Orca and confirm the baseline branch and the current uncommitted changes.
  2. Create/select independent worktrees for Codex and Claude Code.
  3. Copy the common acceptance conditions, and then write out the different subtasks and prohibited ranges.
  4. Ask the Agent to conclude by listing modified files, tests performed, unverified assumptions, and recommended commit instructions.
  5. When finished, read the diff and test output first, and then decide whether to let one of them continue to correct.

Orca also supports opening worktrees from GitHub and Linear tasks, and leaving comments on diff lines back to the Agent. Writing comments in the form of actionable feedback, such as “Keep only tests, withdraw dependency upgrades” or “Explain the cache invalidation sequence here” is more effective than just saying “Make it better”.

How to do “approval” on mobile phone

Orca’s Mobile Companion is used to monitor and guide Agents on your phone: receive notifications when completed and send follow-ups from anywhere. It supports iOS and Android companion apps and needs to be paired with the desktop version.

The “mobile approval” here should be understood as task-level decision-making, not blindly completing Git merge on the mobile phone:

1
2
3
4
通知到达
  → 查看 Agent 的完成摘要、测试状态和风险提示
  → 决定:追问 / 让它补测试 / 停止另一个候选 / 标记为待电脑审阅
  → 回到桌面端查看完整 diff、运行关键测试、再合并

Suitable operations on mobile phones include asking the Agent to explain failed tests, requesting to narrow the scope of changes, adding a regression case, or stopping tasks that are obviously off-topic. Not suitable for approving database migrations, production configurations, permission changes, or extensive refactorings based solely on notification summaries.

A reusable comparison and approval checklist

When both Agents are completed, proceed in this order:

1
2
3
4
5
6
7
[ ] 两个方案是否都基于同一基线分支?
[ ] 是否都列出了修改文件和运行过的测试?
[ ] 是否有一个方案引入了无关依赖或大范围格式化?
[ ] 是否存在同一文件的竞争修改?
[ ] 主方案能否独立通过测试?
[ ] 次方案中是否有可单独挑选的测试、注释或修复?
[ ] 是否已在桌面端审查完整 diff,再执行 merge?

Candidates can be compared in the main working tree before merging:

1
2
3
git diff main...agent/login-fix-codex
git diff main...agent/login-fix-claude
git log --oneline main..agent/login-fix-codex

After confirmation, only merge the adopted branch, or use git cherry-pick to choose to commit separately. Keep the unadopted worktree until the verification is completed, and then clean it up to facilitate finding another idea when returning.

FAQ

Can Codex and Claude Code modify the same file at the same time?

Yes, because they are in different worktrees. But this only avoids overwriting each other during runtime and does not automatically resolve logical conflicts during merge. It is best to designate one master implementation agent and another responsible for testing, review, or alternatives.

Can I merge just by seeing “Done” on my mobile phone?

This shouldn’t be the case. Mobile phones are good for receiving notifications and sending follow-up questions; full diffs, live testing, sensitive configurations, and merge decisions should still be done in a trusted desktop environment.

Why are the results of both Agents unsatisfactory?

Often the task boundaries or acceptance criteria are not specific enough. First let one of the Agents only do code reading and list the root cause assumptions and minimal impact files; after confirming the direction and then starting the parallel implementation, the cost will be lower.

Summary

Orca lets Codex and Claude Code execute in parallel in isolated worktrees, and the real gains come from subsequent comparable diffs, tests, and risk notes. The mobile companion application is suitable for completing “receiving notifications - asking questions - deciding the next step” in advance, but it does not replace the manual complete review and merging with Git. By separating execution, comparison, and approval, code risks will not be amplified due to multi-agent parallelism.

记录并分享
Built with Hugo
Theme Stack designed by Jimmy