GovernCode
pre-alpha · phase 1

GovernCode

Govern your AI coding crew: one Controller, sandboxed Runners, Limits you set, Gates you sign.

Appoint one AI coding tool as the Controller. It hands bounded jobs to the other tools you already use, as Runners. Every job is written down, runs in a deny-by-default sandbox in its own git worktree, and can be diffed and undone. Nothing risky runs until you allow the exact request.

  • MIT licensed
  • runs on your machine
  • no hosted service
  • Linux first, macOS next

Terminal: gov ask asks the Controller to clear a build cache. A Gate shows the exact request as sorted JSON, command rm -rf target/debug/incremental. The user allows it once and the turn is done. Below, a phase 1 preview: Runner Codex is held inside its 10% weekly Limit, which resets Tuesday 06:10, so the Controller does the work itself.

Illustrative session with invented data. The Gate shows the canonical request: sorted keys, ASCII-escaped JSON, exactly what will run.

What it does

Your tools, your rules, one crew

GovernCode does not replace your AI coding tools. It starts them, fences them in, and keeps the record.

  • Controller + Runners

    phase 0–1

    Bring your own AI tools. One leads the project and keeps its own subagents; the others take bounded jobs (Specs) with a brief, scope, budget and acceptance test.

    Controller · Claude Code
    Runner · Codex

  • Gates

    phase 0

    Approve the exact request, byte for byte, not a summary of it. Deny is always available. Today you answer in your own terminal; later you sign on your phone.

    allow runs exactly that input
    no answer means deny

  • Limits

    phase 1

    A measured hold, never paid overage. Each provider keeps the reserve you set. Unknown or stale usage counts as held, and a hold names its reset time.

    gov limits set codex --reserve 10%

  • Sandbox

    phase 0

    Deny by default, self-tested, fails closed. Landlock and seccomp fence every tool: a filesystem allowlist, outbound TCP to 443 only, and one channel to the daemon, so a tool cannot approve its own Gate. If the self-test fails on your machine, nothing starts. There is no unsandboxed switch.

    govern-sup selftest · must pass

  • Checkpoints

    phase 1

    Undo, with guard rails. Every Spec gets a git snapshot before and after, so you can diff it and roll it back. Undo refuses if you changed those files afterwards, rather than overwrite your work. Everything lands in the Trace, an append-only history.

    gov undo S-0412 · restored 1 file

Open source

Free and open source

Free and open source (MIT). Runs on your machine. No hosted service.

Your code, keys and history stay local. The daemon, the sandbox supervisor and the CLI are all in the repo. Nothing is usable by non-developers yet: phase 1 runs a Controller in the sandbox, lets it hand jobs to a Runner, and asks you at every Gate.

build from source
git clone https://github.com/onelegdave/governcode
cd governcode
npm ci && cargo build --release
./target/release/govern-sup selftest

Developers only, for now. Needs Linux 6.12+ (Landlock ABI 6), Node 22.18+, Rust and git. The README has the rest.

Roadmap

Where it stands

Built in the open, in this order. Linux and macOS are first-class; Windows is not supported yet.

  1. phase 0 done

    Foundation

    Daemon, sandbox + self-test, CLI, Claude Code driver, the Trace.

  2. phase 1 now

    The crew

    Delegation and Specs, first measured Runner, Limits, Checkpoints + undo.

  3. phase 2

    Dashboard

    Desktop app for Linux and macOS, review queue, Gates.

  4. phase 3

    Pager

    Phone app, Android first: pairing and phone-signed Gates.

  5. phase 4

    Modules

    Plugins and the Registry that publishes them.

  6. phase 5

    Launch

    iOS, driver Modules, and a proper release.