My Take on Code Reviews with Codex CLI: Choosing Between Local, Hooks, and CI, Plus Permission Boundaries

Yohei Kano (aka Hey9Woz)

Table of Contents

Introduction

Code review often becomes “the last fortress” for quality. But in practice, it’s usually cheaper to catch misalignment earlier than to carry it all the way to the end and then fix it.

Tools like Codex evolve fast and can be used in many different ways. I found myself trying lots of patterns, getting a bit tired of the constant experimentation, and rarely sticking to one approach for long. That’s exactly why I’m writing this: to step back and summarize my own way of splitting usage, at a slightly more abstract level.

My conclusion is that the value of Codex CLI is not “AI reviews my code,” but rather: it reduces review friction and increases the number of improvement cycles.

One more thing matters to me, too. Compared to typical project-specific review checklists, a well-informed AI can point out issues from a broader, more refined perspective. Local checklists are strong, but because they’re optimized for a specific environment, they naturally develop blind spots. That’s where an external perspective helps.

I’m a freelancer and end up working with many different teams. Review cultures vary a lot: the checklist differs by project, and sometimes there’s no checklist at all. So when you bring in an external, consistent set of review angles, it becomes easier for “invisible holes” to surface.

The role that feels right to me is this:

Prepare the code so that humans can read what humans should read.

The review angles behind Codex aren’t just “this project’s taste.” They include ideas that OpenAI and contributors have refined, and that can contain perspectives a single project might never produce. That’s where it stops being “just a convenient tool.”

TL;DR

  • Start with local pre-commit review using /review. Best cost-performance.
  • Automated review via pre-commit hooks is possible, but making it “block” commits is expensive.
  • Restricting permissions makes boundaries clearer. Managing this in config.toml is practical.
  • For serious adoption, shift effort to PR time with GitHub Actions + codex-action.

Why Use Codex CLI for Reviews?

Human review is powerful, but costly. Cost here means time, focus, and cognitive load.

What I want from Codex CLI is not replacing humans. It’s picking up the obvious landmines before humans read.

Also, by “landmines,” I don’t only mean what static analysis catches. Codex often flags “quiet but painful” issues:

  • language/framework pitfalls
  • security and input handling concerns
  • operational and maintainability risks
  • design/ownership boundaries that feel brittle

These aren’t always captured by project-specific checklists, so the added perspective is valuable.

My Conclusion on How to Split Usage

My conclusion is simple. This split tends to last the longest:

  • Local (before commit): fast, light, comments-only (level the ground)
  • Hooks (pre-commit): create a habit trigger (don’t try to be the “blocker”)
  • PR/CI: spend time where it matters (human eyes + AI, careful inspection)

Major Pattern: Local Pre-Commit Review (Local /review)

This is the most common pattern, and the one that tends to work best.

  • Run Codex CLI before committing
  • Use interactive review to improve the changes

The core is: don’t dirty the working tree, read the diff, return feedback only. You keep decision power. That’s what makes it sustainable.

If you’re using the TUI presets, start here:

  • “Review uncommitted changes” (review the uncommitted diff)

Why this works well

  • Issues surface before the change becomes a “done commit”
  • It’s feedback-driven, so the psychological barrier is low
  • It’s the right fit for “pre-processing for human review”

Minor Pattern: Automated Review in pre-commit (Blocking Is Costly)

The next idea people try is this:

  • run review via codex exec (or similar) in a pre-commit hook
  • make it run automatically

Turning commits into a “review event” is nice. If you’re reviewing after commit, the “Review a commit” preset fits.

But there’s a catch.

The common trap

You might want: “if there are findings, stop the commit.” In reality, this is hard.

  • you need a machine-checkable decision format (“block / not block”)
  • output variance and edge cases make it heavy
  • the hook starts feeling like CI, and the operational cost jumps

So I treat pre-commit review as a reflection trigger, not as a hard gate.

Hybrid Is Usually Too Much (You Lose on QCD)

Local review, hook review, PR review… all at once. Quality might improve, but you often lose on QCD (quality, cost, delivery).

If you aim for “perfect review” at the local stage, you burn stamina and the habit dies. I prefer “local = leveling,” “PR = inspection.”

Permission Design: The Tighter It Is, the Clearer Responsibility Becomes

Codex CLI is useful, so drawing boundaries makes it easier to use safely.

There are multiple ways to set permissions:

  • TUI commands
  • startup options
  • config.toml

In practice, commands/options are easy to forget, and typing them every time becomes friction. So I prefer fixing rules in config.toml (user-wide or per-project).

My preferred “permission baseline”

  • editing files is allowed
  • dangerous execution or external access requires approval
  • reviews are primarily comments-only

This makes the boundary obvious.

And yes, it’s obvious, but still important: you are ultimately responsible for the code. In the current era of high-quality outputs, the mindset “AI wrote it. AI said it.” can remain in the background, and sometimes it leaks into the foreground.

As a side note: there are roles where the main arena really is “make AI write it,” such as prompt-focused or algorithm-focused positions. That’s a valid specialization, and responsibility belongs there. The problem is when that responsibility gets misunderstood: people mass-produce code they don’t understand, and then engineers whose goal is not ‘make AI write it’ are forced to read huge diffs, fix bugs, refactor, and document everything to shipping quality. I’ve already seen a few teams drift into that kind of debt.

“Let AI write it” isn’t inherently bad. But if the output is within your responsibility area, you need to accept it consciously. Decide what you’re responsible for before you delegate anything. That’s the real meaning of tightening permissions.

Make It a System at PR Time: GitHub Actions + codex-action

If you want to move from “personal habit” to “team terrain,” this is the step.

  • introduce GitHub Actions + codex-action
  • run automated review on PR creation

Start safely:

  • begin with comments only
  • introduce auto-fixes only after the workflow is stable
  • commit .codex/config.toml into the repo to reduce variation across people

Summary: From Habit to System

For me, Codex CLI isn’t “a tool that makes AI do code review.” It’s a tool that levels the ground so humans can read what humans should read.

  • level the ground locally
  • tighten permissions to stay safe and clear on responsibility
  • make it a system at PR time

When those three are in place, reviews compound. They become a system, not a one-off effort.

Start with /review before commit. That’s the quiet win.

2