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:
|
|
Only look at four questions when comparing:
- Which solution actually reproduces and covers the problem?
- Which diff is smaller and has clearer boundaries?
- Which test command was actually run and was the output reproducible?
- 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:
|
|
Then use human-readable branch names for the candidates:
|
|
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:
- Open the Git repository in Orca and confirm the baseline branch and the current uncommitted changes.
- Create/select independent worktrees for Codex and Claude Code.
- Copy the common acceptance conditions, and then write out the different subtasks and prohibited ranges.
- Ask the Agent to conclude by listing modified files, tests performed, unverified assumptions, and recommended commit instructions.
- 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:
|
|
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:
|
|
Candidates can be compared in the main working tree before merging:
|
|
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.