Updates · 2026-11-05

How the Hive ships itself: 182 releases in 14 days, and what breaks

The Hive (hivelab.ca) is a small team of agents that keeps your Claude Code or Codex work running overnight, on your own machine. It is also, mostly, built by itself. The installer, the site, the guide and the releases come out of the same agent team that you would point at your own work.

This is a build log, so here are the numbers, with dates.

The numbers

Between 22 October and 5 November 2026 the repository (ihsan-sa/hive) published 182 releases. They were not evenly spread. The busiest days were 24 October (65 releases) and 25 October (45). Quiet days had none. On 5 November the latest was v2.3.24.

Most of those early releases were small. When a release costs nothing to make, an agent that fixes one line ships one line. That is fine for a fix. It is a poor way to read a changelog, and we know it.

The release notes are one fixed sentence that points at the README. No model writes text that goes out with a release. We chose that on purpose: the thing most likely to be wrong in a release is a sentence nobody checked.

The train

An agent does not push a release. It lands a change, and a timer called the release train looks at the result every five minutes. At most one release goes out per 30 minutes. For each candidate the train:

1. exports the public tree and scans it for private details;
2. runs the release checks, including a test with a real agent;
3. installs the candidate over a rig of older Hives, to test updating;
4. builds clean images and tries it on real Windows;
5. only then publishes.

If any step fails, the train holds, and one agent is started to find out why. It does not retry in a loop, and it does not skip the step.

What breaks

The train held 34 times between 3 and 5 November (2 times on the 3rd, 25 on the 4th, 7 on the 5th). Looking at why is the useful part, because none of it was dramatic:

• Order of operations. The export ran before two files of the dashboard (a web manifest and a service worker) were saved, so it failed on a tree that was half written. The fix was to export from a frozen snapshot of the extras rather than the live folder.
• A guard that guarded the wrong thing. A site deploy was refused because the site project was in edit mode. The deploy now goes through the edit tool.
• Flaky tests. Sandbox tests had timeouts that held under a quiet machine and failed under a busy one, which is the machine the train runs on. They were fixed on 4 November.
• Outside services. GitHub returned 500 errors on a push, and a token returned 403. Both were fixed on 4 November, with retries for the pushes.
• The updater. An install that found a tool missing from its PATH exited 75, and the updater counted that as a bad release. It now counts as stuck and tries again.

Each of these was fixed by an agent that was started by the hold, and each fix went through the same train.

What it still gets wrong

The train catches an install that fails. It does not catch an install that works but is confusing, and it does not tell us how a release feels to someone using it for the first time. Those still need a person, and today that person is whoever notices.

It also makes a lot of releases. Two hundred in two weeks is a pace that makes a changelog useless, so the next step is to batch the small ones into a weekly note. That note is this page: from now on we will write a short post each Monday with what shipped, in plain words.

If you want to see the train, it is in the open: ihsan-sa/hive, under the release tooling. If you want your own agents kept running overnight, start with the guide.