Codex vs Claude Code for security review in 2026: read-only scanners, patch workers, and worktree boundaries

Posted on by

As of April 27, 2026, the useful Codex vs Claude Code question for security review is not which agent is smarter.

That question is too squishy.

The useful question is which role each agent should play before a risky change reaches your main branch.

Security review is not one job.

It is at least four jobs wearing one hoodie.

There is code exploration.

There is risk finding.

There is patch writing.

There is final acceptance.

If the same AI agent does all four jobs in the same context, with the same permissions, on the same checkout, your review workflow may look efficient while quietly becoming harder to trust.

That is the trap.

The better setup is role separation:

  • use read-only scanners to find risk;
  • use patch workers to make narrow changes;
  • use worktrees to isolate competing edits;
  • use a final review gate before merge, push, or deploy.

Codex and Claude Code can both fit into that pattern.

They just fit differently.

This post is a practical operating table, not a fan chart.

Fan charts are fun until production config gets edited by something that was supposed to be “just reviewing.”

The operating answer

If you use both Codex and Claude Code, do not ask “which one should own security review?”

Ask:

Which agent should read?

Which agent should write?

Which agent should run tests?

Which agent should review the diff?

Which agent should be allowed to touch network, MCP, or release steps?

Here is the short version.

Security-review role Better default Why
Broad repo exploration Claude Code read-only subagent or Codex read-only mode Keeps noisy search away from patch context
PR-style diff review Codex /review or Codex PR review Official review loop is built around diff feedback
Targeted patch implementation Codex worktree or Claude Code worker with limited tools Isolates write authority
Multi-file risky refactor Separate worktree per attempt Prevents one agent from mixing incompatible fixes
Security-policy checks Read-only scanner role Findings should not auto-mutate code
Release approval Human or explicit approval gate Merge/deploy is not a scanning task

The point is not that Codex can only review or Claude Code can only explore.

Both tools can do more than one thing.

The point is that your workflow should not give every role the maximum toolset just because the model can handle it.

Capability is not a permission policy.

Why security review needs role splitting

A human reviewer does not usually edit the whole PR while reviewing it.

They read the diff, leave comments, ask for tests, and approve only after the author responds.

AI workflows often collapse that separation.

The prompt says:

Review this code, fix anything risky, run tests, update files, and commit.

That feels productive.

It is also ambiguous.

When the agent finds an issue, is it acting as reviewer or implementer?

When it rewrites a file, is it preserving the original intent or inventing a new design?

When tests pass, did it verify the security property or only satisfy the existing suite?

When it commits, who accepted the risk?

Those questions matter because security review is not only about finding bugs.

It is about accountability.

Role splitting makes the accountability visible.

The scanner can be wrong.

The patch worker can be wrong.

The reviewer can be wrong.

But when their outputs are separated, the mistake has a shape.

You can inspect it.

You can reject it.

You can improve the role instruction that failed.

When one agent does everything in one long thread, failure turns into soup.

Soup is fine for lunch.

Less ideal for audit trails.

What Codex is good at in this workflow

Codex is especially strong when you want a review-and-verification loop attached to a concrete code change.

OpenAI’s Codex best-practices documentation explicitly recommends asking Codex to create tests when needed, run checks, confirm the result, and review the work before accepting it.

The same guidance describes /review for reviewing against a base branch, uncommitted changes, a commit, or custom review instructions.

That makes Codex a good fit for:

  • reviewing a diff;
  • checking for regressions;
  • running project-specific test commands;
  • applying small patches;
  • comparing worktree output;
  • following repo-level AGENTS.md rules;
  • using a shared code_review.md standard.

Codex also has a clear worktree story.

The Codex app documentation says worktrees let Codex run multiple independent tasks in the same project without interfering with each other.

That matters for security review because parallel review experiments can get messy.

One agent may propose a dependency upgrade.

Another may propose input validation.

Another may suggest deleting a feature.

You do not want all three edits landing in the same checkout at once.

Worktrees let each attempt stay reviewable.

That is boring infrastructure with real value.

What Claude Code is good at in this workflow

Claude Code is strong when you want specialized subagents with explicit tool limits.

Its subagent documentation describes specialized assistants that run in their own context, with custom prompts, specific tool access, and independent permissions.

It also includes built-in read-only subagents such as Explore and Plan, designed for code search and planning without write access.

That maps nicely to security review.

For example:

  • a read-only explorer can inspect auth flow;
  • a security reviewer can search for risky patterns;
  • a dependency analyst can inspect package files;
  • a database query validator can examine query construction;
  • a patch worker can receive a narrow fix request later.

The important part is tool restriction.

Claude Code docs show that subagents can be configured with allowed tools or disallowed tools.

For a read-only reviewer, the docs explicitly describe selecting read-only tools and leaving Write/Edit out.

That is exactly what a first-pass security scanner should do.

It should find and explain risk.

It should not silently fix the repo while it is still discovering the system.

The wrong comparison

The wrong comparison is:

Codex or Claude Code, which one is better at security?

That question hides the workflow.

The better comparison is:

Workflow need Prefer this role shape
Find risky patterns across many files Read-only scanner
Explain architecture risk Read-only researcher
Fix one concrete bug Patch worker
Run tests and type checks Verification runner
Review a patch against base branch Diff reviewer
Decide whether to merge Human gate

Once you frame it that way, “Codex vs Claude Code” turns into a routing question.

Codex may be your diff-review and worktree implementation loop.

Claude Code may be your subagent-based exploration and specialized scanner layer.

Or you may invert that for your own setup.

The key is not brand loyalty.

The key is not letting the same agent hold every authority by default.

A four-role security-review pipeline

Here is the pattern I would use for a small team.

Role 1: read-only scanner

Purpose:

Find possible risks without changing files.

Allowed:

  • read files;
  • search code;
  • inspect diffs;
  • inspect dependency manifests;
  • read tests;
  • produce findings.

Blocked:

  • edit files;
  • run destructive commands;
  • install packages;
  • access secrets;
  • push or commit;
  • modify agent config;
  • call broad MCP tools.

Output:

  • finding list;
  • file references;
  • severity;
  • confidence;
  • suggested test;
  • suggested fix shape.

This role should be boring and narrow.

It should not be clever with patches.

Its job is to see.

Not to touch.

Role 2: patch worker

Purpose:

Apply one accepted fix in an isolated checkout.

Allowed:

  • edit files inside the assigned scope;
  • run relevant local tests;
  • update focused tests;
  • produce a diff summary.

Gated:

  • new dependencies;
  • network access;
  • broad refactors;
  • files outside scope;
  • MCP tool changes;
  • secret access;
  • commit or push.

Output:

  • patch;
  • test output summary;
  • unresolved assumptions;
  • rollback note.

This role should receive a narrow instruction.

Bad:

Fix all security issues.

Better:

Fix the missing authorization check in ProjectController.update, add a regression test, and do not touch unrelated routes.

The patch worker should not decide the entire review scope.

It should implement a scoped decision.

Role 3: verification runner

Purpose:

Confirm the patch did not break known behavior.

Allowed:

  • run tests;
  • run lint;
  • run type checks;
  • inspect diff;
  • compare before/after behavior.

Blocked:

  • broad code edits;
  • release actions;
  • unrelated cleanup.

Output:

  • commands run;
  • pass/fail;
  • notable failures;
  • whether failures are related;
  • recommended next action.

This role can be Codex, Claude Code, CI, or a boring shell script.

Do not over-romanticize it.

Security review still needs plain old verification.

Role 4: final gate

Purpose:

Decide whether the change can merge, ship, or be handed to a human reviewer.

Allowed:

  • read findings;
  • read patch;
  • read test results;
  • request changes;
  • approve next step.

Gated:

  • merge;
  • push;
  • deploy;
  • package publish;
  • production config change.

Output:

  • accept;
  • reject;
  • request changes;
  • defer to human expert.

This role is where the workflow earns trust.

The final gate should not be the same context that read hostile input, invented the patch, and declared victory.

That is a little too “I investigated myself and found no issue.”

The worktree boundary

Worktrees are not a security product.

They are a change-isolation tool.

That still matters.

Codex worktree docs describe worktrees as a way to run independent tasks in the same project without interfering with each other.

Git’s own worktree model allows multiple working trees attached to one repository, while each checkout has its own files.

For AI security review, that gives you a useful boundary:

  • one branch or detached checkout per patch attempt;
  • one diff per agent task;
  • one review thread per change hypothesis;
  • no accidental mixing of fixes;
  • easier rollback.

This is especially useful when reviewing security changes because security fixes often tempt agents into broad edits.

An agent sees unsafe input handling.

Then it sees outdated dependency versions.

Then it sees missing tests.

Then it sees duplicated helper code.

Suddenly the “security fix” is a whole architecture migration wearing sunglasses.

Worktrees help keep that energy contained.

Give each attempt a sandbox of code state.

Then compare outputs.

Do not let every idea mutate the same working directory.

The read-only scanner pattern

The read-only scanner is the most underrated role.

It should have one job:

Find risk without gaining authority.

Example prompt:

Review this repository for authentication and authorization risks.
Use read-only inspection only.
Do not edit files.
Do not run install commands.
Do not call network tools.
Return findings with file paths, evidence, severity, confidence, and a suggested test.

For Claude Code, this maps well to a read-only subagent.

For Codex, this maps well to read-only permissions or a review-focused prompt against a diff.

The scanner’s output should be structured.

Field Why it matters
Finding Names the suspected issue
Evidence Shows why the scanner thinks it matters
File path Makes it reviewable
Severity Helps prioritization
Confidence Prevents false certainty
Suggested test Converts risk into verification
Suggested fix shape Guides the patch worker

Do not ask the scanner to fix its own findings.

That is a different role.

Keep the scanner hungry but handcuffed.

In a friendly way.

The patch worker pattern

The patch worker should not receive the whole codebase and a motivational poster.

It should receive an accepted finding.

Example:

Implement the accepted finding SEC-003.
Scope: src/auth/session.ts and tests/auth/session.test.ts only.
Goal: reject expired refresh tokens before issuing a new access token.
Add or update tests.
Run the targeted auth test suite.
Do not refactor unrelated session code.

This is where Codex worktrees shine.

Start a patch attempt in a worktree.

Let the worker edit there.

Review the diff before moving it to local.

Claude Code can do this too, especially with a custom worker subagent and worktree isolation.

The main rule:

The patch worker should not be allowed to expand the scope silently.

If it finds a second issue, it should report it.

Not fix it in the same patch.

Security patches that fix five extra things are harder to audit.

The phrase “while I was here” has caused more review pain than many actual bugs.

The reviewer pattern

The reviewer should see the final diff, not the entire messy conversation that created it.

Codex’s /review model is useful here because it can review against a base branch, uncommitted changes, or a commit with custom instructions.

Claude Code can also run a dedicated code-review subagent, especially if the subagent has read-only tools and a specific security checklist.

The reviewer should ask:

  1. Does the patch fix the accepted finding?
  2. Is the patch too broad?
  3. Are tests meaningful?
  4. Did the patch introduce a new trust boundary?
  5. Did the agent add dependencies?
  6. Did it change config?
  7. Did it touch secrets, logging, auth, or network paths?
  8. Is rollback obvious?

The reviewer should not be impressed by large diffs.

Large diffs are not inherently suspicious.

But they do require more evidence.

Security review rewards smaller patches because smaller patches are easier to reason about.

Tiny patch, meaningful test, clear boundary.

That is the good stuff.

Where Codex fits best

Use Codex when the task is close to:

  • review this diff;
  • run the expected tests;
  • apply a scoped patch;
  • compare changes in a worktree;
  • follow repository instructions;
  • use AGENTS.md and code_review.md consistently;
  • generate or update tests around a concrete change.

Codex works well as the patch loop when the repo already has clear commands.

For example:

Use the accepted finding SEC-004.
Make the smallest patch.
Run npm test -- auth.
Then run /review against the uncommitted changes with security focus.

That pattern uses Codex as implementer and reviewer, but still separates phases.

Implementation first.

Review second.

Acceptance later.

The separation matters even if the same product handles multiple phases.

Where Claude Code fits best

Use Claude Code when the task is close to:

  • explore this codebase without editing;
  • create a specialized reviewer;
  • separate context-heavy research from the main thread;
  • use a subagent with limited tools;
  • scope MCP access to a specific agent;
  • run parallel research tasks;
  • maintain reusable agent definitions in .claude/agents/.

Claude Code’s subagent model is especially useful for repeated review lanes.

Example subagents:

Subagent Tools Job
auth-scanner Read, Grep, Glob Find auth and session risks
dependency-reviewer Read, Grep, Bash limited to package inspection Review manifests and lockfiles
db-query-reviewer Read, Grep Look for unsafe query construction
patch-worker Read, Edit, Write, Bash Implement scoped accepted fixes
release-checker Read, Bash Verify final branch state

The tool list is the product.

If every subagent inherits everything, you mostly created costumes.

Costumes are fun.

Security boundaries are better.

The comparison table

Here is the practical routing table.

Need Codex default Claude Code default Safer decision
Review a PR diff Strong fit Strong with reviewer subagent Use either, keep read-only
Run tests after patch Strong fit Strong fit Keep command list explicit
Explore large codebase Good Strong with Explore/Plan Use read-only role
Create reusable reviewer roles AGENTS.md plus review docs Subagent files Use both if team has both
Parallel implementation attempts Codex worktrees Subagent worktree isolation or manual Git worktrees One worktree per attempt
MCP-heavy review Use approvals and sandbox Scope MCP per subagent Avoid broad default MCP
Final merge/deploy Approval gate Permission gate Human or controlled release lane

This table is not timeless.

Tools will keep changing.

The boundary pattern will age better than the feature list.

A simple team workflow

For a small engineering team, use this sequence:

  1. Read-only scanner runs on the branch.
  2. Human or lead agent triages findings.
  3. Patch worker receives one accepted finding.
  4. Patch worker works in a worktree.
  5. Verification runner runs targeted tests.
  6. Diff reviewer reviews the patch against base.
  7. Human approves merge or requests changes.

That sounds like more steps.

It is fewer surprises.

The trick is to make each step small.

Small scanner output.

Small patch.

Small test command.

Small review.

Small approval.

Security review gets worse when every step becomes one giant agent monologue.

What to put in AGENTS.md

For Codex, repository guidance matters.

OpenAI’s best-practices docs recommend using AGENTS.md to encode how the team wants Codex to work, including build, test, lint, conventions, PR expectations, constraints, and done criteria.

For security review, add a short section like this:

## Security Review Workflow

- Start with read-only review for security findings.
- Do not edit files during the scanner phase.
- Findings must include file path, evidence, severity, confidence, and suggested test.
- Patch one accepted finding at a time.
- Run targeted tests before broad tests.
- Do not add dependencies without approval.
- Do not modify secrets, CI, deployment, or MCP config without approval.
- Review final diff before acceptance.

This is not fancy.

It is useful because it gives the agent something stable to follow.

If Codex makes the same review mistake twice, update this section.

Guidance should be a scar map, not a constitution.

Tiny, accurate, earned.

What to put in a Claude Code subagent

For Claude Code, create a read-only security reviewer subagent.

Example shape:

---
name: security-readonly-reviewer
description: Use for read-only security review of code changes. Does not edit files.
tools: Read, Grep, Glob
model: sonnet
---

You are a security reviewer.
Inspect code for auth, input validation, secret handling, logging, dependency, and network risks.
Do not edit files.
Return findings with file path, evidence, severity, confidence, and suggested test.
If you need to run commands or modify files, stop and ask for a separate patch-worker step.

Then create a separate patch worker.

---
name: security-patch-worker
description: Implements one accepted security finding with narrow scope.
tools: Read, Edit, Write, Bash
model: sonnet
isolation: worktree
---

Implement only the accepted finding.
Respect the file scope.
Add or update focused tests.
Do not change dependencies, CI, deployment, secrets, or agent configuration unless explicitly requested.
Return a diff summary and test results.

The point is not the exact wording.

The point is that the reviewer and the patch worker are not the same authority.

What not to automate

Do not fully automate:

  • dependency upgrades that change runtime behavior;
  • auth-policy rewrites;
  • cryptography changes;
  • production logging changes;
  • secret rotation;
  • CI credential changes;
  • deployment config;
  • MCP server installation;
  • permission relaxation;
  • database migration execution;
  • public package publishing.

Agents can help prepare these changes.

Agents can draft patches.

Agents can run local checks.

But the final action should be gated.

Security review is not only about code correctness.

It is about deciding what risk the organization accepts.

Models can assist that decision.

They should not silently own it.

Common failure modes

Failure 1: the scanner edits files

This breaks the clean evidence trail.

Fix:

Make the scanner read-only.

If it finds a bug, produce a finding.

Then route the finding to a patch worker.

Failure 2: the patch worker expands scope

This makes review harder.

Fix:

Give the worker explicit file ownership.

Require it to report additional findings instead of fixing them.

Failure 3: the reviewer trusts test pass too much

Tests can pass while security remains broken.

Fix:

Require the reviewer to connect the test to the threat.

For example:

“This test proves expired refresh tokens are rejected before new access tokens are issued.”

Not just:

“Tests pass.”

Failure 4: worktrees multiply without cleanup

Worktrees are useful until they become a closet full of half-finished branches.

Fix:

Name them by finding ID.

Delete rejected attempts.

Promote accepted attempts to branches.

Keep a small active limit.

Failure 5: MCP access leaks into every role

The scanner gets GitHub, database, browser, Slack, and filesystem tools because they were available in the main session.

Fix:

Scope MCP access by role.

Read-only scanner gets only what it needs.

Patch worker gets less, not more.

Release lane gets explicit approval.

The minimum viable setup

If you want the simplest version, do this:

  1. Create a read-only security review prompt.
  2. Create a narrow patch prompt.
  3. Use a separate worktree for patch attempts.
  4. Run targeted tests.
  5. Review the diff before merge.
  6. Require approval for network, dependencies, MCP config, secrets, push, and deploy.

That is enough to get most of the benefit.

You do not need a giant multi-agent platform on day one.

You need one clean rule:

The agent that finds risk should not automatically become the agent that changes the system.

The final rule

Codex vs Claude Code is the wrong ending.

Security review in 2026 is not a single-agent competition.

It is a workflow design problem.

Use Codex where diff review, worktree implementation, tests, and repository guidance are strong.

Use Claude Code where subagents, read-only exploration, tool scoping, and reusable specialist roles are strong.

Then make the boundary visible.

Read-only scanner.

Patch worker.

Verification runner.

Final gate.

That is the shape.

The tools can change.

The boundary should stay.

Related Reading

FAQ

Should Codex or Claude Code own security review?

Neither tool should own every step by default.

Use role separation.

A read-only scanner finds risk, a patch worker fixes accepted findings, a verification runner checks behavior, and a final gate accepts or rejects the change.

Is a read-only AI reviewer useful if it cannot fix code?

Yes.

Read-only review is useful because it preserves evidence and avoids accidental mutation during discovery.

Fixing belongs in a later patch-worker step.

Are worktrees a security boundary?

Not in the same sense as a sandbox.

Worktrees are a change-isolation boundary.

They keep parallel attempts and diffs separate, which makes review and rollback easier.

Can one agent perform multiple roles?

Yes, but separate the phases.

For example, Codex can implement a patch and then run /review, but the implementation phase and review phase should have different instructions and clear outputs.

What should require human approval?

Require approval for dependency changes, network access, MCP configuration, secrets, CI, deployment, push, package publishing, production config, and broad permission relaxation.

μ°Έκ³  자료/곡식 좜처