Back to Projects

2026 · Engineering

Hive

A multi-agent harness that turns Claude Code, Gemini CLI and Codex into one coordinated team working on a single repository

Project Summary

Hive brings the official coding agents (Claude Code, Gemini CLI and Codex), each running on the user’s own computer and logged in to its own subscription, together into one team called a fleet. One agent, the orchestrator, plans the work and keeps the user informed but never writes code. The others, the workers, pick up tasks, lock the files they edit and merge their work into main once the tests pass. The user approves the plan, answers the questions only they can answer and watches everything live.

It uses no vendor API keys. It drives the official CLIs through their documented features: headless and interactive modes, MCP servers, hooks and plugins.

My Role

I owned two parts of the project. The first is the interface: the web dashboard where agents, tasks, file leases, pending decisions and live output are watched and steered from one screen. The second is OpenAI Codex CLI support: running Codex headless and resuming its sessions, a private CODEX_HOME profile per agent, role-based command rules, hooks that enforce file leases on Codex’s patches too, and sandbox permission modes. I verified the Codex support with tests that use canned responses and with end-to-end tests against the real Codex CLI.

How It Works

  • The server is the single source of truth: agents, tasks, messages, file leases, decisions waiting for the user, live output and the web dashboard. It is a plain Python web app with no background processes, so it runs on PythonAnywhere or a small VPS.
  • A daemon runs on every computer that hosts agents: it checks the server every few seconds, starts agents when there is work and runs their git operations.
  • The agents are the unmodified vendor CLIs. Hive attaches its tools, hooks and instructions only to the sessions it launches; a session the user opens themselves is unaffected.

Features

  • Every agent works in its own git worktree on its own branch; finished work is rebased onto the latest main, tested and pushed automatically
  • A task board: the orchestrator splits the goal into tasks and the server hands each one to an idle agent whose role fits
  • File leases: an agent must lock every file it edits, and hooks refuse any other write
  • A message board with channels, direct messages and priorities; urgent messages reach an agent even mid-turn
  • Built-in roles (orchestrator, programmer, planner, reviewer, tester) plus custom ones
  • A web dashboard with agents, tasks, file leases, pending decisions, command approvals and highlighted live output on one screen; the fleet can be steered from a phone too
  • Three-tier command permissions: routine commands run directly, dangerous ones such as git push and rm -rf need the orchestrator’s approval, and commands that would let an agent act as the user never run
  • Mixed fleets across Windows, macOS and Linux, several accounts per computer and several projects per server

Two Rules That Always Hold

Both are enforced in code by the server and the hooks, not by asking the AI models nicely:

  • No agent writes code until the user approves the plan.
  • When an agent is stuck on something only the user can resolve, the whole fleet freezes until they answer.

Technologies Used

PythonFlaskMCPSQLiteGit worktreesClaude CodeGemini CLICodex CLIpytest
Back to Projects