codeArbiter

Inspiration

AI coding agents are increasingly capable, but teams still need durable rules: explicit decisions, test-first changes, review gates, and audit evidence that survive beyond one chat session. codeArbiter makes those controls repository-native so they travel with the code instead of living in a single vendor's interface.

What it does

codeArbiter is a governance layer for AI coding agents across Claude Code, Codex CLI, and Pi. All three hosts share the same .codearbiter project state, architectural decisions, task board, approval boundaries, reviews, and verification evidence.

During OpenAI Build Week, I closed the Pi parity gap. Pi now has:

• A global rich status footer, with repository-specific statistics shown only for trusted, enabled codeArbiter repositories
• Explicit allow / ask / deny execution policy
• A read-only plan mode, except for active planning artifacts
• Session-scoped background jobs that are never restored after Pi shuts down
• Bounded child-agent dispatch for single, chained, and parallel work
• Process-tree cleanup, context compaction, and actionable diagnostics

How I built it

The implementation combines a shared TypeScript and Python governance core with generated host adapters and command surfaces for Claude Code, Codex, and Pi. Repository-owned .codearbiter files are the source of truth. Vitest and Python suites, live process-tree probes, security acceptance checks, documentation generation, and multi-OS GitHub Actions validate the contract.

Codex with GPT-5.6 was the primary implementation partner for planning, coding, reviews, tests, CI diagnosis, documentation, and release evidence. It also assembled the narrated demo from repository and CI evidence when I ran out of time while heading to pick up my daughter from daycare.

Challenges

The hard part was achieving parity without creating divergent clones. Pi also required first-class permission-question semantics, a trust boundary before interpreter activation, reliable Windows process-tree cleanup, and strict lifecycle guarantees for session-only jobs. CI runner instability made it important to preserve local and hosted verification evidence separately.

Accomplishments

This is verified production work, not a slide prototype:

• 46 canonical release gates
• 38 Pi acceptance criteria
• 1,057 hook tests
• 198 farm tests
• 12/12 Pi security controls
• 18/18 live process-tree variants
• 418/418 documentation-site tests across 129 generated pages and 18,483 checked links

The parity pull request consolidates 16 source pull requests, 29 commits, and 126 changed paths.

What I learned

Host parity works best when the shared semantic contract comes first and each host receives only the adapter it needs. Permission questions must be a first-class platform capability, not an error fallback. Lifecycle and teardown behavior need live testing, especially on Windows. Visible diagnostics and durable receipts make governed agentic work easier to trust.

What's next

Next steps are a tagged ca-pi release, additional execution modes built on the policy core, richer mode and status telemetry, and promotion of future capabilities only after acceptance evidence proves them.

AI disclosure

GPT-5.6 assisted with implementation, review, verification, documentation, and video assembly. Engineering and project ownership remain with me; the demo video is AI-assisted. I ran out of time and Sol remotely did the video, voice over, and upload while I drove across town to get my daughter from daycare.

Built With

• claude-code
• codex
• github-actions
• gpt-5.6
• pi
• python
• typescript
• vitest