What Is codeArbiter

codeArbiter is one governance product with three host adapters: ca for Claude Code, ca-codex for Codex, and ca-pi for Pi. The Claude Code marketplace also carries ca-sandbox, an infrastructure plugin unrelated to gate enforcement (see ca-sandbox); the Codex marketplace carries ca-codex, while Pi uses npm with pinned Git tags as the reproducible channel. All three governance adapters inject the same orchestrator responsibilities, enforce the same policy core, and use one checked-in .codearbiter/ directory for project context and audit state. See the Claude Code + Codex evidence for the verified boundary between those two, and Pi for the third host’s install and trust model. The complete ca-pi adapter is currently a Feature Forge preview: real use and feedback are welcome while broader testing continues before stable status.

codeArbiter Holds the Gates; You Hold the Decisions

This is the organizing principle. codeArbiter enforces process; you make the calls. It holds the gates: the test-first rule, the review chain, the secret and crypto checks, the commit and merge boundaries. Work does not pass a gate without clearing it. But the decisions those gates surface belong to you. Which design? Which trade-off? Whether to merge? Those are yours to make. When a gate finds something worth your attention, it reports the finding plainly and waits for your call. It does not resolve the question on your behalf.

How a Request Flows

1. Command. Invoke /ca:feature in Claude Code or $ca-feature in Codex. The generated command surface differs in spelling, not ownership or policy.
2. Route. The orchestrator hands the command to the workflow that owns that lane. /ca:fix and $ca-fix both reach the same test-first obligations.
3. Execute the roles. The owning skill selects the author and reviewer roles the change actually demands. Claude Code dispatches plugin agents. Published releases from 0.7.5 include the complete packaged resource charter set for that release for Codex host-provided agent threads, with exact static-package and route-closure checks at release. A bounded 0.9.4 receipt proves one exact installed-charter review. Adapters may use the bounded inline fallback only where the canonical workflow explicitly permits it and isolation is not mandatory. Pi launches hardened child processes through its trusted parent. The policy stays shared even though each host’s mechanism differs.
4. Gate. Nothing advances until its gates are green. A failing test, a CRITICAL security finding, an unresolved decision: each is a real stop.
5. Ship. Code reaches version control only through the commit gate, and the default branch only through a pull request. Never a direct write.

One lane, five steps: command, route, gate, ship to a PR.

Gate

A gate is not advice you can wave off. It is the only path that kind of change takes to ship. When a gate trips, codeArbiter surfaces the decision and waits for you to resolve it.

Context Minimization

codeArbiter is built so almost nothing loads until it is needed. The only always-loaded context is one file, the orchestrator persona, injected by a SessionStart hook, and only in repositories whose project state opts in. A repo that hasn’t opted in loads nothing at all.

Everything else is paid for on demand: the routing table, the reference map, every skill body, every agent body, the design-quality reference bundle. A node loads only when an entry point reaches it. A typical /ca:fix touches the persona, the test-first skill, one author, and maybe one reviewer. It never pulls the whole payload. Read-only meta commands like /ca:status, /ca:btw, and /ca:commands route to no skill at all.

The Lanes

Work is organized into lanes. Each is a sanctioned path with gates scaled to its risk.

• Implementation: /ca:feature (checkpointed), /ca:sprint (autonomous, every auto-decision SMARTS-scored), /ca:fix, /ca:refactor, /ca:debug, /ca:chore, /ca:spike.
• Commit & ship: /ca:commit, /ca:pr, /ca:watch, /ca:checkpoint, /ca:tribunal, /ca:release, /ca:add-dep. /ca:checkpoint is the lean periodic sweep; /ca:tribunal is its rare, deep counterpart: an on-demand, resumable whole-codebase audit by eleven specialist lenses that files findings as GitHub issues on your approval and is never a required gate.
• Decisions: /ca:adr, /ca:adr-status, /ca:reconcile, /ca:conflict, /ca:threat-model.
• Project & meta: /ca:init, /ca:status, /ca:audit, /ca:doctor, /ca:btw, and more.

See Concepts for the ideas behind the lanes, and the Reference for the full, auto-generated catalog of commands, skills, and agents.