# Codex plugin for Claude Code: two read-only reviews, one transcript transfer, and a build that needs Codex

> codex-plugin-cc is a Claude Code plugin that adds a set of /codex commands for asking Codex to review work or to take a task, and it is distributed through Claude Code's plugin marketplace rather than npm. Two of its commands are read-only reviews that differ in whether they can be steered, one command hands your Claude Code transcript to Codex, and the build itself cannot run without the Codex CLI installed because the prebuild step generates its types from Codex.

**openai/codex-plugin-cc** — This plugin lets Claude Code send repository tasks to Codex for implementation or a second code review.

- Repository: https://github.com/openai/codex-plugin-cc
- Stars: 33,723 · Forks: 2,352
- Language: JavaScript
- License: Apache-2.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/openai-codex-plugin-cc

## Two review commands that differ in exactly one capability

The plugin ships two review commands and the difference between them is the most useful thing in the README.

`/codex:review` runs a normal Codex review on your current work, and the README says it gives you the same quality of code review as running the review command inside Codex directly. It can review your uncommitted changes or a branch against a base like main with `--base <ref>`, and it supports `--wait` and `--background`. It is explicitly not steerable and does not take custom focus text.

`/codex:adversarial-review` runs a steerable review that questions the chosen implementation and design, to pressure-test assumptions, tradeoffs and failure modes, and to ask whether a different approach would have been safer or simpler. It uses the same target selection, so `--base` works, and unlike the first one it accepts extra focus text after the flags, for example challenging whether a caching and retry design was right or asking it to look for race conditions.

Both are read-only. The second is stated not to fix code. So the choice is not strength, it is whether you want a second opinion on the diff or a challenge to the direction behind it.

## The transfer command reads your Claude Code transcript and imports it

`/codex:transfer` is the one command with a data flow you should read twice. It creates a persistent Codex thread from the current Claude Code session and prints a resume command for that session id. The use case is continuity: you started a debugging conversation in Claude Code and want to continue the same context in Codex.

The mechanics are worth knowing. The plugin already has a SessionStart hook that supplies the current transcript path automatically, and `--source` is a manual override for when it does not. The source file has to be under `~/.claude/projects`, and the transfer uses Codex's external-agent session importer, so it follows the same conversion rules as importing Claude history into the Codex app, and it creates visible turns that can be continued in the app or the TUI. Older Codex versions that do not expose session import have to be upgraded before this command works.

The consequence is direct. Running this sends a transcript of your conversation, including whatever code and paths were discussed, to Codex. The path constraint and the version requirement are documented; the privacy decision is yours.

## The build cannot run without the Codex CLI installed

Look at the scripts in the manifest. The prebuild step creates a directory under the plugin and then runs a Codex command to generate TypeScript types from it, writing the output into a generated folder inside the plugin. The build step is then a plain TypeScript compile against a dedicated tsconfig, and the test step is Node's built-in test runner over the files in tests/.

So the build order is: Codex must already be installed and able to run its app server command, because that is where the plugin's types come from, and only then does tsc run. There is no vendored type file to fall back on and no script to install Codex for you, unlike the setup command in the plugin itself, which can offer to install Codex when npm is available.

That is a real constraint for a contributor. Cloning this repository, running the tests and seeing them fail because a tool is missing is the expected first experience. The development dependencies are minimal by comparison, a TypeScript compiler and the Node type definitions.

## The package is private, so the marketplace is the only way in

The manifest says private: true, and the name is a scoped one, @openai/codex-plugin-cc, at version 1.0.6. Nothing about it is meant to be installed from npm. The only npm package in this workflow is Codex itself, installed globally with `npm install -g @openai/codex`, and the login step when Codex is installed but not yet authenticated is a shell escape out of the conversation.

Installation is three Claude Code commands and then a setup check. Add the marketplace, install the plugin from it, reload plugins, and run the setup command:

```bash
/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup
```

The setup command tells you whether Codex is ready, and if Codex is missing and npm is available it can offer to install it. If you would rather do that yourself, the Codex package is installed globally with `npm install -g @openai/codex`, and a Codex that is installed but not yet authenticated needs `!codex login`, which is a shell escape out of the conversation.

The repository holds a .claude-plugin/ directory, which is the plugin manifest Claude Code reads, alongside a plugins/ directory, a scripts/ directory for the version tooling, tests/, and a tsconfig dedicated to the app server types.

After installation the README says you should see the slash commands listed in the file, and a subagent named for codex rescue appearing in the agents list. That second item is the visible sign that the subagent half of the plugin loaded, and it is the half that handles delegation rather than review.

## Background is the recommended mode, not the exception

Three separate notes in the README tell you the same thing, which makes it a design decision rather than a caveat. Code review, especially for multi-file changes, might take a while and is generally recommended to run in the background. Tasks handed to Codex, depending on the task and the model, might take a long time, and it is generally recommended to force the task to be in the background or move the agent to the background. And the first run the README suggests is a review in the background followed by a status check and a result check.

The commands that make that work are three. `/codex:status` shows running and recent jobs for the current repository and can take a job id, `/codex:result` shows the final stored output for a finished job and includes the Codex session id so you can reopen that run, and `/codex:cancel` cancels an active job.

So the plugin is built around asynchronous delegation with a small job queue you can inspect, rather than a blocking call. If you want it synchronous, `--wait` is there. The default expectation is the other one.

## The model is your choice unless you leave it out, and spark is an alias

The delegation command takes more flags than the review commands, and the notes under it are the part to read. It supports `--background`, `--wait`, `--resume` and `--fresh`, and if you omit the last two the plugin can offer to continue the latest rescue thread for that repository, so a follow-up request picks up where the previous one stopped.

You can also pick the model and the effort explicitly, as in a cheaper model with medium effort for a flaky integration test, or the literal word spark, which the plugin maps to a specific Codex model name. And the first note is the one that saves you a decision: if you do not pass a model or an effort level, Codex chooses its own defaults.

You can also skip the command entirely and just ask, since the plugin will delegate a request phrased as a task for Codex. Combined with the follow-up behaviour, that means a debugging session can be a conversation with a model that keeps its own thread, which is closer to working with a colleague than to calling a function.

## A review gate you can switch on, and version bumps with a check

The setup command does more than verify the install. It checks whether Codex is installed and authenticated, offers to install Codex if it is missing and npm is available, and it is also where you manage the optional review gate, with an enable flag and a disable flag.

A gate is a workflow rule rather than a tool, and the README does not describe it further in the text available here, so what it gates and when is something to establish by running it. What is clear is that it is optional and that the switch lives in the same place as the install check, which is a sensible place for it.

The versioning is also scripted. There is a bump script and a check mode of the same script, so the manifest version and the plugin metadata can be verified rather than trusted, and the release tags follow that number: v1.0.6 on 2026-07-08, v1.0.5 on 2026-06-23 and v1.0.4 on 2026-04-18. The last push to the repository was on the same day as the newest tag.

## Conclusion

Use codex-plugin-cc if you already work in Claude Code and want a second opinion from Codex, either as a read-only review of your uncommitted changes or as a background task for a bug you have not diagnosed. Do not use it to have Codex write into your working tree, because both review commands are documented as read-only and the only command that changes anything is the one that hands work over deliberately. Before you install: have a ChatGPT subscription, including the free tier, or an OpenAI API key ready, and remember that usage counts against your Codex limits; have Node 18.18 or newer; read the transfer section before you use it, because it reads your session transcript from ~/.claude/projects and imports it into Codex; and run /codex:setup afterwards, since that is what checks Codex is installed and authenticated and where you turn the optional review gate on.

## FAQ

### What is a codex plugin?

In this repository it is a Claude Code plugin, distributed through Claude Code's plugin marketplace rather than npm, that adds a set of slash commands. The commands are a read-only review, a steerable adversarial review, and five for delegating work and managing background jobs, plus a setup command that checks Codex is installed and authenticated.

### How to install codex plugin cc?

Add the marketplace in Claude Code with `/plugin marketplace add openai/codex-plugin-cc`, install with `/plugin install codex@openai-codex`, reload with `/reload-plugins`, then run `/codex:setup`. You also need a ChatGPT subscription, including the free tier, or an OpenAI API key, and Node.js 18.18 or newer. Codex itself is installed with `npm install -g @openai/codex` if you would rather do it yourself.

### Which is better, Codex or Claude Code?

The plugin's premise is that you use both rather than choose. It is for Claude Code users who want an easy way to start using Codex from the workflow they already have, and its review commands are described as giving the same quality of review as running the review command inside Codex directly. The adversarial command adds a steerable pass that questions the chosen design.

### Is codex a VS Code plugin?

The README does not mention VS Code at all. This is a Claude Code plugin, installed by adding a marketplace and installing a plugin from it inside Claude Code, and its commands are slash commands in that interface. The only separate tool it depends on is the Codex command line, installed globally with npm.

## Sources

- [Official README](https://github.com/openai/codex-plugin-cc#readme)
- [Project repository](https://github.com/openai/codex-plugin-cc)
- [Release notes](https://github.com/openai/codex-plugin-cc/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openai-codex-plugin-cc