You already have two coding apps. Claude Code is Anthropic’s terminal app that edits a repo. Codex is OpenAI’s terminal app that does the same job with a different model. A coding agent (the app that reads files and runs commands) is not the model (the program that writes the next words). Each app is already a harness (the loop, the tools, and the permissions around that model).
People open both, point them at one folder, and hope the second one reviews the first. The handoff is a copy-paste. Close the laptop and the second pane is gone.
Run Claude Code and Codex together with the implementation-pair starter, not first-project: first-project boots two Codex seats in one folder, and a real setup rewrites both app config files.
The picture is the pair you actually want: one writer, one checker, a handoff between them. The rest of this page is how to get that pair, and the starter that looks like it but is not.
Why two terminals still drop the handoff
Two terminals drop the handoff because neither app knows the other exists. You are the router.
A seat (a named job you can message again later) is what a second window is missing. You type claude in one pane and codex in the other. Each chat dies with that window. There is no address that still means “the writer” after a reboot.
That is fine for one review you finish today. It breaks when the checker has to come back and still know which diff it was looking at.
How to run Claude Code and Codex together
Boot a rig (a YAML file that lists the seats and how work moves) only after you open the starter that matches the job.
I installed OpenRig CLI 0.5.17. OpenRig (a local control plane that launches these apps as one team) ships the starters as YAML inside the package. I opened the files. I did not trust the quickstart line.
Here is what those files actually say.
first-project has two members, owner and check. Both set runtime: codex. Both set model: gpt-6-astra. Both set cwd: ".". One edge (a handoff from one seat to another) runs from owner to check.
implementation-pair is the Claude Code and Codex pair. impl sets runtime: claude-code. qa sets runtime: codex. The edge runs from impl to qa. This file does not pin a model name.
conveyor is four seats in a line: Claude Code, then Codex, then Claude Code, then Codex. Intake, plan, build, review. Use it when you want a queue, not a pair.
A pod (the group of seats that share one working folder) is the dev block in the pair files. Both members use the same folder. That risk is the next section.
Left is the starter people will copy first. Right is the one that matches the question in the title.
The README I read still tells you to message dev-owner@first-project. The file in this CLI names the seats owner and check, not dev-owner. Do not copy a send command from a blog, including this one, until rig up --plan prints the real addresses.
What I changed, and what I refused to change
I ran rig setup --dry-run. A dry-run (a preview that writes nothing) listed nine steps and skipped every one of them.
A real rig setup, without that flag, may edit these files:
~/.claude.json, to pre-trust workspaces and mark Claude onboarding complete.claude/settings.local.jsonin the project, for a status line and an acceptEdits floor. The preview said it does not bake an allow, ask, or deny list.mcp.json, for selected Claude tool-server fragments. MCP (a small server that lets the app call a tool) is the thing that file wires up~/.codex/config.toml, to pre-trust workspaces and apply Codex fragments
I did not run rig setup without --dry-run. Back up those four files, then read the preview on your machine. The list can change.
The preview also offered a permission policy: Locked, Standard, Open, YOLO, or none. I picked none. If you skip, the tool says it sets nothing beyond a usability floor. Do not pick YOLO because a blog made it sound fast.
Then I ran rig up first-project --cwd . --plan. Plan mode (a preview of the launch, still no agents) stopped on one line: tmux was not found. tmux (a terminal that keeps sessions alive after you close the window) is required. rig doctor agreed. Node was fine. The daemon files were present. Port 7433 was free. tmux failed.
No tmux, no team. That stop happened before any agent launched, and before any config file was rewritten. Install tmux first so you are not debugging a missing program after the tool has already edited Claude and Codex.
Can I point Claude Code and Codex at the same folder?
You can, the shipped pair does, and that is the risk.
Both seats in implementation-pair set cwd: ".". Two agents with write tools in one folder can edit the same file. A worktree (a second checkout of the same git repo, on its own branch) is the safer split when both of them write.
Use one folder when one seat writes and the other only reviews, and you are watching. Use two worktrees when both can run shell commands while you are away.
git worktree add ../repo-review -b reviewPoint the checker at ../repo-review. Point the writer at the original folder. They no longer share a writable tree.
If the fear is “this agent can delete the wrong thing”, the isolation writeup is the coop sandbox. A rig does not replace a fence. It only names the seats.
If your real problem is “both apps should call the same model”, that is a different page. Claude Code and Codex on the same model is the gateway and the nine slots. This page is the team, not the brain.
Claude Code and Codex together: plugin, worktrees, or a rig
Use a Codex plugin inside Claude Code when you want one front door and a second opinion on a diff. You stay in Claude. Codex is a command you call. You do not get a seat that is still there after you close the laptop. I did not install that plugin in this test.
Use two git worktrees when the tasks are independent. Claude takes one branch. Codex takes another. You are still the person who copies the result across.
Use OpenRig when you want named seats and a handoff that is a line in YAML, and you accept two costs: setup can edit both config files, and tmux has to exist before rig up will plan anything.
Skip OpenRig when you do not have a Codex login. The getting-started page for the smallest starter says it needs authenticated Codex. Skip it when you only have Claude Code. An empty seat is a longer way to open one terminal.
Skip it when you wanted a boss, a task board, and a company of agents. That job is already the Paperclip versus Orca post on this blog. OpenRig is seats and handoffs. It is not an org chart.
Also skip a rig if the agents ignore your house rules. A messy CLAUDE.md makes every seat do extra work. The harness around the model is the same idea as the learn-claude-code teardown: tools, a loop, a boundary. A YAML team does not fix a bad boundary.
| You want | Use this | Do not use |
|---|---|---|
| One review while you stay in Claude | Codex plugin inside Claude Code | a four-seat conveyor |
| Two branches at once | two git worktrees | one shared folder |
| Claude writes, Codex checks, and you can message them again | implementation-pair | first-project |
| Both apps on one model | the gateway setup | a rig |
Try this before you boot a rig
Eight minutes. No agents started. This is the test I ran, plus the one check I could not finish without tmux.
- Install tmux, then run
tmux -V. - Run
npm install -g @openrig/cli. - Run
rig --version. Confirm the build before you trust a starter name. - Run
rig setup --dry-run. Read every file path. Back those files up. - Open
first-project/rig.yamlandimplementation-pair/rig.yamlin the installed package. - Confirm the writer runtime says
claude-codeand the checker sayscodex. If both saycodex, you opened first-project. - Only after tmux exists, run
rig up implementation-pair --cwd . --plan. - Only then decide if
rig setupwithout--dry-runis worth the edits.
The repo is mvschwarz/openrig. The install notes are on Getting started.
Questions people actually ask
Can I run Claude Code and Codex on the same repo without them overwriting each other?
Yes, if only one of them writes, or if each one has its own worktree. No, if you boot the shipped pair and walk away. Both seats use the same folder.
The overwrite is not a bug in git. It is two writers with one checkout.
Is OpenRig worth it if I only need a second opinion?
No. Call Codex from inside Claude Code and ask for a review. A rig is extra machinery for a single comment on a diff.
Use the rig when the checker is a seat you will message again, not a one-off.
Why does rig up stop before it shows a plan?
Because tmux is missing. Install it, then run the plan again. On my machine the command exited before any agent started.
rig doctor is the shorter version of the same check.
Should I use first-project or implementation-pair?
Use implementation-pair when you want Claude Code to write and Codex to check. Use first-project only when you want two Codex seats.
Read the YAML. The name first-project sounds like the beginner path for both apps. In this CLI it is not.
Boot the pair that matches the job, and read the dry-run before you let it touch your config.
4 comments