Codex auto review can get expensive

Auto review is one of those features that feels small until it shows up in the usage graph.

The point of it is good. Codex can keep working inside the sandbox, and when an action crosses a boundary, a reviewer can inspect the request instead of stopping the whole session for manual approval.

But if the work keeps crossing that boundary, the reviewer becomes another active model in the loop. On a heavy day, that can turn into a real usage line of its own.

In my case, the large review line pointed to work that crossed trust boundaries too often.

What auto review is actually doing

Auto review leaves the sandbox unchanged. It reviews actions that would already need approval: sandbox escalations, blocked network access, protected file writes, side-effecting connector or MCP calls, and similar boundary crossings.

So the underlying shape is usually this:

normal project work
        |
        v
agent wants to cross a boundary
        |
        v
approval request
        |
        v
auto-review model evaluates the request
        |
        v
allowed, denied, or sent back for user attention

When that happens once or twice, it is fine. When it happens every few minutes, each boundary crossing adds another model turn.

Why it starts taking over

In my recent Codex work, mixed-scope sessions caused most of the repeated review turns.

The same conversation would move between ordinary application code and things with a much wider blast radius:

• editing global Codex config under ~/.codex
• changing reusable skills and agent role files
• rebuilding Docker services
• inserting rows into a running development database
• staging and committing a dirty worktree
• checking whether a config file still contained secrets
• touching MCP credentials or provider authentication paths

Those are all legitimate tasks. They just should not be treated like ordinary component edits.

How to tell what is causing the turns

The fastest way to debug auto-review usage is to inspect the boundary crossing behind each request.

Start with the approval request itself. Ask what the agent was trying to do at that moment:

• Was it writing outside the current workspace?
• Was it touching ~/.codex, .git, .agents, credentials, or profile files?
• Was it running Docker, SSH, Git, package install, or a database command?
• Was it reaching the network from a sandboxed command?
• Was it using an MCP or app tool with side effects?
• Was a broad command like "commit all" forcing scope review?

Then check the surrounding task structure. A normal UI change followed by Docker rebuilds, browser validation, database inserts, and a commit combines several trust levels in one session.

A simple way to sort the work:

low review pressure
  source edit -> focused test -> local browser check
 
medium review pressure
  source edit -> Docker rebuild -> service health check
 
high review pressure
  source edit -> global config -> secrets boundary -> commit all -> running DB

If auto review is the largest usage line, the task probably spent too much time in the medium and high lanes.

Safe ways to reduce it

Keep the boundaries explicit. Repeated review turns usually indicate that the task needs a narrower scope or a separate privileged step.

For normal repo work, keep the default posture boring: workspace write, bounded network, and approvals for anything outside the project. Most application edits should stay inside that shape.

For global Codex maintenance, use a separate maintenance task or profile. It is reasonable to make a deliberate session that edits ~/.codex/skills or ~/.codex/agents. It is much less reasonable to let every web-app task wander into those directories without a visible mode shift.

For Docker and database work, split the runtime mutation from the code change. First make the repo change. Then run the container or database step as its own explicit operation. That makes it easier to see whether the review cost came from the build, the database write, or the app code.

For Git, avoid vague commands when the tree is dirty. "Commit all" is useful, but it forces the agent to inspect everything, scan for secrets, and decide whether unrelated changes are in scope. A narrower instruction, such as "commit only the users list density change," creates less review pressure and less risk.

For repeated safe commands, use narrow allow rules instead of broad access. Approving a specific npm run build or project smoke-test command is different from giving the agent broad write access to the home directory.

For secrets, keep the rule simple: externalize them first. A config file that still contains tokens should remain hard to write, stage, or publish.

What I would like from OpenAI

The reviewer job itself feels like a good candidate for local inference, at least for repetitive low-risk approval checks.

The reviewer is often deciding whether a command is inside an expected pattern: a known test command, a known Docker health check, a narrow file write, or a repeat of an already reviewed operation. That kind of judgment still matters, but it is also exactly the sort of bounded classification work that could be cheaply handled by a local model when the policy allows it.

Any local-review path should preserve the safety boundary and escalate secrets, destructive commands, broad filesystem access, network exposure, Git publishing, and anything the local model cannot classify with confidence to the stronger hosted reviewer.

That would keep the safety feature while making the cost easier to accept.

Where I landed

For now, I turned off auto review.

I kept the sandbox and approval boundaries, then changed my Codex configuration so some safe, repetitive work can run without constant review.

Routine checks no longer burn the same part of the usage graph. Config changes, secrets, broad filesystem access, destructive commands, Git publishing, and live service changes still remain visible.

After I separated privileged maintenance from ordinary repository work, the remaining review turns mapped more clearly to actions that deserved attention.