← Back to articles

Local Models for Code Review in Claude Code

4 min read
  • Claude Code
  • Codex
  • Local models
  • Code review

local-model-plugin-cc started from a practical question: what if the code review and rescue workflows I use with Codex could run from Claude Code while keeping the model call on my machine?

Hosted models are still the default for many agentic coding workflows, and often for good reason. They are easy to start, consistent, and usually strong at tool calling. But local models have a different set of advantages. They make experimentation cheaper. They let sensitive repository context stay closer to the developer workstation. They also make model behavior more inspectable because the endpoint, model, and runtime are all explicit parts of the setup.

The project is a Claude Code plugin that delegates review, adversarial review, and rescue tasks to local models through OpenAI’s codex CLI. The source is on GitHub at BenBish/local-model-plugin-cc, and the shape is intentionally close to openai/codex-plugin-cc: keep Claude Code as the command surface, keep Codex as the execution engine, and swap the model provider at runtime.

The Architecture

The plugin is a thin broker over the codex CLI. Claude Code commands call broker scripts in the plugin package, and those scripts invoke codex exec with the right sandbox and model provider configuration for the job.

The important part is that the model provider is not written into a long-lived config file. Each run passes ephemeral model_providers overrides with -c, pointing Codex at a local OpenAI-compatible endpoint. The common paths are Ollama at localhost:11434, LM Studio at localhost:1234, or a custom endpoint supplied by the user.

That keeps the plugin small. It does not need to implement an agent runtime, repository scanner, tool loop, or sandbox. Codex already has those pieces. The plugin’s job is to translate Claude Code commands into the right Codex invocation and make the local-provider setup ergonomic.

The Commands

/local:setup is the starting point. It detects common local model servers, preferring Ollama and then LM Studio, or lets the user configure a custom OpenAI-compatible endpoint. After a model is selected, it smoke-tests the configuration so failures show up before a review or rescue task is running.

/local:review runs codex exec review against uncommitted changes, or against a supplied base ref with --base <ref>. It uses a read-only sandbox because review should observe the repository, not mutate it. The expected output is structured, file-grounded findings rather than a broad essay about the code.

/local:adversarial-review uses the same target selection but changes the posture. It is meant to challenge assumptions, look for failure modes, and stress the design rather than only checking the obvious diff mechanics.

/local:rescue is the implementation path. It delegates a coding task through codex exec under a workspace-write sandbox, then applies a post-hoc diff-safety check before treating the result as usable. That second gate matters because local models vary widely in instruction following and tool behavior.

The background job commands, /local:status, /local:result, and /local:cancel, keep longer local-model runs manageable from Claude Code without adding a separate worker runtime.

Why This Shape Works

The central design choice is restraint. Local model tooling can easily grow into a parallel agent framework: custom job queues, custom config files, custom patch formats, custom review schemas. This plugin avoids that. Codex remains responsible for sandboxing and execution. Claude Code remains responsible for the developer-facing command surface. The plugin only owns the bridge between them.

That makes the project useful in a few concrete situations:

  • You want a second-pass reviewer that can inspect a branch without sending repository context to a hosted model.
  • You want an adversarial pass over design or failure modes while keeping the workflow inside Claude Code.
  • You want to compare Ollama, LM Studio, and custom OpenAI-compatible local endpoints against the same repository task.
  • You want a rescue workflow for contained implementation tasks, but still want Codex’s sandbox behavior and a follow-up diff check.

It is also honest about the tradeoff. Local models are not automatically safer or better just because they are local. They still need reliable tool calling, enough context length for the repository task, and a review process that treats generated findings as candidate findings. The plugin helps by making the execution path explicit and by keeping mutation behind sandbox choices and reviewable diffs.

Testing Without a Local Model Server

The repository tests the broker behavior with Node’s built-in test runner and a fake codex binary fixture. That means CI can validate command construction, sandbox choices, background job behavior, and failure handling without requiring Ollama, LM Studio, or a live local model during the test run.

That testing boundary matches the architecture. The plugin should be confident that it invokes Codex correctly. Model quality, latency, and endpoint behavior are runtime concerns that belong in smoke tests and real local usage.

The Larger Point

local-model-plugin-cc is not trying to replace hosted coding models. It is a small compatibility layer for a different operating mode: run Claude Code workflows, keep Codex’s execution model, and point the model call at infrastructure the developer controls.

That is the part I find most useful. Local models become another provider choice rather than a separate workflow. The command stays familiar, the sandbox stays explicit, and the experiment remains easy to throw away if a model is not good enough for the task.