Using dev-orchestra with Codex

Introduction

Last time, I used dev-orchestra in a Claude Code-only environment. This time I’m installing it in Codex.

To cut to the chase: it works with Codex alone. But my top recommendation is to install both Claude Code and Codex. That way, you automatically get a setup where AIs from different companies review your code.

For what dev-orchestra actually does, see the introduction post.

dev-orchestra is open source on GitHub (MIT license). If it looks useful, a star would mean a lot.

→ github.com/istb16/dev-orchestra

Requirements

Item	Notes
Codex CLI	Already logged in
Python 3.11 or later	Runs on the standard library only
git	Used to get the diff to review

No API key is needed. It uses your existing Codex login.

Steps

1. Install it

Two lines in the terminal.

codex plugin marketplace add istb16/dev-orchestra
codex plugin add dev-orchestra@dev-orchestra

You can check that it’s installed with codex plugin list.

2. Pick a preset on first use

Getting started is the same as with Claude Code. The first time you make a request that uses dev-orchestra, it asks you for a preset. If unsure, go with standard. I’ll cover what’s in each preset in detail later in this series.

3. Check the Codex-only setup

On a machine without Claude Code, choosing standard gave me this setup (excerpt from config show in dev-orchestra 1.0.0).

Preset: standard (implicit; fitted to codex)
  note: claude not found on PATH: reviewer seat 2 (general) was not added; it would repeat codex-general
  note: claude not found on PATH: reviewer seat 4 (test) was not added; codex has no cheap model named offline

  Architect
    codex / recommended-coding / latest
  Implementer
    codex / recommended-coding / latest
  Reviews
    1. codex / recommended-coding / latest / general / codex-general
    2. codex / recommended-coding / latest / security / codex-security

Design, implementation and review are all assigned to Codex.

There’s one difference from the Claude Code-only setup: there are 2 reviewers instead of 4.

The second general seat would be exactly the same Codex as the first, so it is not added
The test seat is meant for a “cheap model”, and Codex has no cheap model that can be named, so it is not added

Putting the same AI in the same role twice is pointless, so it doesn’t create useless seats in the first place.

4. Add Claude Code to get the recommended setup

This is the setup I recommend. If Claude Code is also installed on the same machine, the setup changes to this.

Preset: standard (implicit; fitted to claude, codex)

  Architect
    claude / fable / latest
  Implementer
    claude / opus / latest
  Reviews
    1. claude / opus / latest / general / claude-general
    2. codex / recommended-coding / latest / general / codex-general
    3. claude / sonnet / latest / security / claude-security (opus when high-risk)
    4. claude / sonnet / latest / test / claude-test

The second reviewer is now Codex.

Claude implements, and both Claude and Codex review
AIs from different companies have different blind spots. Where they disagree on the same diff is where the real bugs are

Without touching any settings, it picks this shape automatically based on the CLIs installed.

If you want Codex to handle design or implementation, you can change the AI for each role. I’ll show how to rearrange them later in this series.

5. Check that everything is ready

Ask the agent “Run the dev-orchestra doctor”. The Codex part looked like this (excerpt).

Codex CLI (codex)
  Installed: yes
  Model selection: supported
  Read-only runs: enforced by -s read-only (CLI sandbox); filesystem writes are blocked by the sandbox (measured); MCP servers were not examined, so external side effects are not covered

The design and review roles run in Codex’s read-only sandbox. The sandbox blocks file writes. However, it honestly states that MCP servers were not examined (also covered in the table below).

If it ends with No problems found., you’re ready.

6. Make a one-sentence request

From here it’s the same as with Claude Code: just talk to it as usual.

Implement this issue with the configured workflow

The flow from the plan-approval prompt to the final report is as described in the previous post.

Running multiple reviewers uses more tokens than a single AI would. I recommend starting with small requests.

Codex-specific features and limitations

Things worth knowing when using it with Codex (as of dev-orchestra 1.0.0; see providers.md for details).

	Details
Plus: Read-only is enforced by the sandbox	Design and review run with `-s read-only`, which also blocks writes from the shell
Plus: Uses the “recommended” model as is	The default is `recommended-coding`. Other models can only be specified if they appear in `dev-orchestra model list`
Plus: Can resume from a previous design	Can continue the previous design conversation, still read-only (on verified Codex versions)
Caveat: MCP servers and hooks are not examined	dev-orchestra does not guarantee against external side effects via MCP tools such as Slack
Caveat: Can read outside the working directory	Unlike Claude, reads are not confined. It can read secret files like `.env` inside or outside the repository, and what it reads is sent to OpenAI
Caveat: Only 2 reviewers with Codex alone (for `standard`)	Because it skips the seat that would duplicate Codex and the cheap-model seat. `quality` gives 4, `fast` usually 1 (+1 for risky changes)
Caveat: Design resume doesn’t work with a custom `model_provider`	If you use a custom provider in `config.toml`, the resume fails and it runs fresh instead
Caveat: Implementer sandbox settings come from the global config	If you put `sandbox` / `approve` in the project config file, implementation runs are refused

To be safe, keep secret files where reviewers can’t reach them. For code that must never leave your machine, you can also review with a local LLM (mentioned in the introduction post).

When updating the plugin, codex plugin marketplace upgrade alone doesn’t install the new version. Run codex plugin add dev-orchestra@dev-orchestra afterwards.

Summary

Installing in Codex is also two lines. No API key needed
It works with Codex alone. Design, implementation and review all go to Codex, with 2 reviewers (for standard)
Add Claude Code for the recommended setup. Both Claude and Codex review, so AIs from different companies review independently
Design and review run in Codex’s read-only sandbox. However, MCP and hooks are not examined
When updating, run plugin add again after marketplace upgrade

For detailed usage, see the README. Next time, I’ll try it with Antigravity.

For how to update when a new version comes out, see Updating dev-orchestra.

All posts in this series are in the list of “dev-orchestra” posts.

GitHub: istb16/dev-orchestra (a star is always appreciated)