Grok Build for Code Review in Claude Code

grok-plugin-cc started from the mirror of a local-model question: what if the same Claude Code review and rescue commands could run against a hosted frontier model, with billing and safety made explicit instead of hidden?

I already had local-model-plugin-cc for Ollama, LM Studio, and other OpenAI-compatible local endpoints (write-up). That plugin keeps Codex as the execution engine and swaps the model provider at runtime. For Grok, the right harness turned out to be different. The source is on GitHub at BenBish/grok-plugin-cc: Claude Code stays the command surface, but execution goes through xAI’s official Grok Build CLI in headless mode.

Why Not Codex + xAI?

The first design tried to point Codex at xAI with custom provider overrides, the same general pattern as the local-model plugin. That path is intentionally gone.

Codex 0.142.0 requires wire_api=responses. Against xAI’s /v1/responses endpoint, Codex’s agent tool declaration (type: namespace) was rejected. Until that compatibility story is proven fixed, reintroducing Codex as the Grok harness would paper over a real API mismatch. The current plugin spawns grok -p ... --output-format json instead and lets the Grok Build runtime own tool calling, sandbox flags, and model selection.

That is the main architectural fork from the local sibling: shared job store, diff-safety, schema validation, and command shape (/local:* versus /grok:*); different execution CLI and auth model.

The Architecture

The plugin is a thin broker. Claude Code slash commands call scripts under plugins/grok/scripts/. Those scripts resolve the git repo identity, load the model id chosen during setup, and spawn the grok CLI with mode-specific flags.

Authentication is owned by the CLI (grok login or any auth method the CLI supports). The plugin stores only the selected model id. It does not store API keys.

Review jobs run headless Grok with JSON output, a review findings schema, sandbox settings, and explicit deny rules for write/edit tools. Rescue jobs use a workspace sandbox, then a second gate inside the plugin: snapshot the repo before the run and reject path escapes, symlink escapes, binary or oversized files, too many changed files, or a moved HEAD. Rate-limit errors are retried with capped exponential backoff based on string matching Grok CLI error text, because the CLI does not expose structured HTTP status to the broker.

The Commands

/grok:setup is the starting point. There is nothing to auto-detect on a loopback port. The command lists available CLI models, configures a default, and smoke-tests the full path with a trivial grok -p --output-format json prompt so auth and CLI wiring fail before a real review.

/grok:review reviews uncommitted changes, or a supplied base ref with --base <ref>. Output is structured, file-grounded findings rather than a freeform essay. The broker runs review with a read-oriented sandbox plus explicit Write(*) / Edit(*) deny rules so the pass is not relying on prompt hygiene alone.

/grok:adversarial-review uses the same target selection with a different posture: challenge assumptions, look for failure modes, and stress the design rather than only checking obvious diff mechanics.

/grok:rescue is the implementation path. It is billed against the configured xAI account and can run for a long agentic session, so the command asks for confirmation first. After Grok finishes, the plugin’s diff-safety checks decide whether the result is acceptable.

/grok:status, /grok:result, and /grok:cancel manage background jobs without adding a separate worker runtime.

Safety and Cost Caveats

Unlike local models, every review, adversarial review, and rescue is billed. Rate limits and pricing live on xAI’s side; the repo does not hardcode rates that will drift. Rescue is the expensive path, which is why confirmation stays in the command definition.

Local spike testing also found that Grok’s --sandbox read-only alone was not enough to block writes. Review safety therefore relies on those explicit write/edit deny rules plus prompt instructions. The deny rules are load-bearing, not decoration.

Rescue can still make real file changes. The post-hoc checks are a second gate, not a substitute for reviewing the diff yourself.

What Was Tested

Automated verification on the plugin repo (Node’s built-in test runner plus TypeScript check) passed cleanly: 73 tests, 0 failures, and npm run lint (tsc) clean. The suite uses a fake grok binary fixture so CI never needs a live xAI account. Coverage includes setup, job store behavior, rate-limit retries, schema validation, and rescue diff-safety rejections (symlink escape, binary files, oversized files, concurrent commits, too many changed files).

A live raw smoke through the installed Grok Build CLI also succeeded: headless grok -p with --output-format json and --max-turns 1 returned a parseable JSON envelope whose text payload was the expected {"ok":true} object, using the grok-4.5 model. That confirms auth, CLI presence, and the basic headless JSON path. It is not a full billed review or rescue quality evaluation.

The plugin’s own setup.mjs smoke-test path is stricter: it adds --sandbox read-only, pins -m grok-4.5, and enforces a 30 second process timeout. On the same machine, that brokered smoke timed out even though the raw CLI call completed successfully. That is an open first-run setup risk: a working Grok login can still look broken if the smoke budget is too tight for a cold CLI run.

Why This Shape Works

The useful constraint is the same one as the local plugin: do not grow a parallel agent framework. Claude Code remains the developer-facing command surface. Grok Build remains the execution engine. The plugin owns the bridge, the job records, the schema check, and the rescue safety gate.

That makes the project useful when:

• You want Grok as a second-pass reviewer or adversarial reader inside Claude Code.
• You want a rescue workflow that is confirmation-gated and post-checked, not a silent long-running rewrite.
• You want the same command family as the local-model plugin, with a clear hosted versus local split.
• You need an honest story about why Codex-as-xAI-provider did not work, and what replaced it.

The Larger Point

grok-plugin-cc is not trying to replace Claude Code’s own model for everyday work. It is a small compatibility layer for a different operating mode: keep the slash-command workflow familiar, point the heavy review or rescue pass at Grok Build, and keep cost, sandbox limits, and failure modes visible.

Paired with local-model-plugin-cc, the pair is a simple provider matrix. Same command shape. Local inference when you want control and free iteration. Hosted Grok when you want a frontier model on the same rails.