Codex Has Become a Claude Code Plugin — Do I Still Need Three Windows Open?

Author: Lu Dayuan Tags: Artificial Intelligence

The last thing I want to do right now is copy the same requirements three times.

Halfway through a conversation in Claude Code, I want Codex to review something again. First I have to organize the background, switch to another terminal, and tell it again where the project is, what changed, and which files it can't touch. After Codex gives its opinion, I move the result back.

If Cursor is also open on the side, the desktop quickly turns into a familiar mess: three windows all claim they understand, but I'm the only one unsure who holds the latest version.

So when I saw OpenAI's August 24 update, my first reaction was simple: someone is finally ready to merge the windows.

OpenAI announced it is deprecating codex mcp-server and moving to the Codex app server instead. The next sentence was even more interesting: if you want to use Codex inside Claude Code, install the Codex plugin for Claude Code.

This isn't an adapter script written by the community. The plugin repository sits under OpenAI's official GitHub organization. It lets Claude Code hand off a code review or an independent task to Codex, then query the status, retrieve the result, and cancel the task if necessary.

It sounds smooth: Claude handles the conversation, Codex handles the work. But after reading through the commands in the official repository, I actually felt this is much bigger than "one less terminal."

In the past we kept arguing about whether to choose Codex, Claude Code, or Cursor. Now the tool vendors' answer is starting to become: you don't necessarily have to pick one, but you do have to decide who sits in the driver's seat and who only gets called when needed.

The core content of OpenAI's August 24 update. The original text points to both the new app server and the Claude Code plugin. Source: OpenAI Release Notes.

What This Plugin Can Actually Do for You

Let's rein in the imagination first.

Codex entering Claude Code does not mean the two Agents suddenly share one brain, nor does it mean Claude Code's entire conversation will be handed over verbatim as Codex's context.

Judging from the capabilities disclosed in the official repository, it's more like connecting a colleague next to Claude Code who can be called upon.

You can have Codex do an ordinary read-only review, or an adversarial review with follow-up questions. When a task gets stuck, you can use rescue to hand the work over; after the task runs in the background, use status to check progress and result to get the outcome. The official release also provides management entry points like transfer and cancel.

What interests me most about this design isn't the number of commands, but the deliberate separation of "review" and "execution."

An ordinary review follows a read-only path. Codex can read code, find problems, and give opinions, but it shouldn't casually modify files. When you actually want to delegate a task, you separately specify the working directory, write permissions, and goals.

This closely resembles the normal relationship in code review: asking someone to find flaws does not mean handing them your keyboard too.

After using many AI tools for a while, the interface quietly blends these two things together. You originally just ask "is there any risk here," and the Agent starts modifying after looking; after modifying it runs a few more commands. The result might be great, but the person's attention has shifted from "judging whether the suggestion is correct" to "tracking down what it just touched."

Putting Codex into Claude Code via the plugin actually gives a chance to redraw the line: which requests are just a second opinion, and which requests are worth launching another executor.

Several types of entry points currently disclosed by the official plugin. Organized in Chinese for readability; command names kept as-is. Source: OpenAI official GitHub repository.

I Won't Let Two Agents Be Equals

Once tools can call each other, the easiest misconception is to understand multi-Agent as "call more people, get work done faster together."

Real-world collaboration isn't like that. Two people modifying the same requirement simultaneously, with no one responsible for the final judgment, usually doesn't mean twice the speed — it means an extra round of merging, explaining, and rework. Agents are the same.

I prefer to fix one primary Agent.

It is responsible for preserving the complete background of the current task: why the user raised this requirement, what boundaries the project has, what trade-offs were made before, and where this round of changes intends to go. Daily discussions, task breakdowns, and result summaries all stay here.

The other Agent doesn't need to know the whole story. It only takes a task that is as small as possible and can be independently verified.

For example, after the primary Agent has completed a round of modifications, I let Codex do a read-only check on this diff, focusing on out-of-bounds changes and exception paths that weren't covered. Or a certain test keeps failing; I give Codex the error, the relevant files, and the scope it's forbidden to change, and let it diagnose independently. When the result comes back, the primary Agent still decides whether to adopt it based on the original goal.

I won't let Claude Code and Codex both hold "final interpretive authority."

This phrasing sounds a bit serious, but it avoids a very annoying scenario: A finishes modifying according to its own understanding, B sees it and then refactors according to another understanding, and in the end the human spends twenty minutes figuring out why both sides think they were fixing the problem.

The most hassle-free combination isn't two main drivers, but one primary Agent that preserves complete context, plus a specialized Agent with clear task boundaries.

The primary Agent is suited for retaining requirement background, driving work forward, and doing final summaries. The called-upon Codex is better suited for tasks with clear boundaries and verifiable results: read-only code review, failed test diagnosis, independently implementing a small change, or raising counterexamples to an existing proposal.

If a task can't be clearly described in a few sentences — the input, the allowed modification scope, and the acceptance criteria — I won't rush to hand it off. That usually means the task hasn't been broken down properly yet.

Fewer Windows, But Four Bills Remain

Putting Codex into Claude Code can indeed save one round of manual copying and might also save some back-and-forth switching. But it won't automatically eliminate collaboration costs.

The first bill is context.

The plugin can hand off a task, but that doesn't mean all historical conversations, implicit constraints, and temporary decisions will follow along. Hand off too little content, and Codex can only guess; hand off too much, and you'll stuff irrelevant information and outdated conclusions in together.

The second bill is permissions.

Read-only review and writable tasks are not the same risk. If a delegated task can execute commands, write to the workspace, and access the network, the working radius it receives still needs to be confirmed separately. You can't default to a vague impression of permissions just because the entry point is inside Claude Code.

The third bill is quota.

The same piece of work, first analyzed by one Agent and then fully reviewed by another, is essentially duplicate consumption. A second opinion is very valuable, but it shouldn't become a fixed ritual after every single-line code change. Otherwise what you save is the person's switching time, but what you increase is the call quota and waiting time on both sides.

The fourth bill is the easiest to overlook: who does the acceptance.

Codex giving a review doesn't mean the problem has been fixed. Claude Code making modifications based on the review doesn't mean the original requirement has been met. When the outputs of two Agents are stacked together, someone still ultimately has to check the diff, the test results, and the boundaries that weren't touched.

I don't think this is a platitude. Once tools start calling each other, the chain of responsibility becomes easier to hide inside pretty automation. With only one command left in the window, it's easy for a person to mistakenly think there was only one execution in between.

One fewer window doesn't mean one fewer set of context, permission, quota, and acceptance costs.

How I Would Hand a Task to Codex

If I had to use this plugin today, I wouldn't start by studying a dozen commands. I would first fix a very short handoff checklist.

It has only six items: the problem to solve, the allowed read scope, the allowed modification scope, the content forbidden to touch, the verification that must be executed, and the evidence to bring back upon return.

For example: check the most recent diff of the payment callback module; can read module code and tests; forbidden to modify files; focus on finding duplicate callbacks and signature verification omissions; return specific file locations, risk explanations, and suggested tests — don't just give a conclusion.

This kind of task is very suitable to hand to a second Agent. It doesn't need to guess what the project will do next quarter, nor does it need to understand all the historical debates. It just needs to see one thing thoroughly.

Another type suitable for handoff is failure recovery: the primary Agent has already tried two rounds, and the test still reports the same error. At this point, handing the error, the relevant diff, the directions already ruled out, and the files allowed to be modified to Codex is more valuable than letting the original Agent keep circling on the same train of thought.

But if the requirement is still "optimize this module a bit," I won't hand it off. A vague task given to two Agents usually just yields two stylistically different vague modifications.

A task handoff checklist you can fill out directly. The point isn't to write formally, but to ensure the receiver doesn't have to guess permissions and acceptance criteria.

This checklist has an unexpected bonus: it forces the person initiating the task to admit whether they've really thought it through.

If "where am I allowed to modify" can't be filled in, the task boundaries aren't clear; if "how to verify acceptance" can only be written as "looks normal," the requirement hasn't landed on a checkable result; if "what evidence to bring back" is empty, it means the final outcome will most likely just be a sentence saying "completed."

No matter how smart the Agent is, it shouldn't silently fill in these decisions on behalf of the person.

So, Will I Still Have Three Windows Open?

Probably not all the time.

If the Codex plugin's actual stability and context handoff meet expectations, I'll fix Claude Code or another tool as the primary window for the current task, and when I need independent review, reverse questioning, or failure rescue, I'll hand a small piece of work to Codex.

Cursor won't disappear because of this either. In-editor instant completions, visual diffs, and local modifications are still a different rhythm of use. I just don't need three tools simultaneously talking around the same requirement.

This update didn't answer "who is stronger, Codex or Claude Code" for me. It made me more certain that what's worth comparing next isn't the overall leaderboard, but roles.

Who is suited to long-term context keeping? Who is good at reading diffs? Who is suited to taking over stuck tasks? Who should only have read-only permissions? At which step must the result return to human hands?

Once these positions are arranged well, having one more Agent is like having one more helper.

If they aren't arranged well, it's just three windows folded into one.

This article is based on OpenAI's August 24, 2026 product update and the openai/codex-plugin-cc official repository. No hands-on testing of the same repository was conducted for this article; the plugin's context loss, stability, and actual quota costs in complex projects still require subsequent testing.