# Hive review: run Claude Code, Codex and Gemini as a local PTY team

> Hive is a browser workbench that turns several CLI coding agents into a visible local team, with an Orchestrator dispatching workers over real PTY processes. It is local-first and Node 22 only, and its licence is not OSI open source.

**tt-a1i/hive** — Browser-native hive-mind for CLI coding agents — Claude Code, Codex, Gemini, and OpenCode collaborate as real PTY processes via a team protocol.

- Repository: https://github.com/tt-a1i/hive
- Website: https://hivehq.dev
- Stars: 557 · Forks: 69
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/tt-a1i-hive

## The coordination gap Hive targets

One CLI agent is easy. Four of them are a scheduling problem. The README lists the symptoms plainly: long-running sessions spread across terminals, no routing layer for splitting implementation, review and testing, worker progress disappearing into scrollback, and restart recovery depending on each CLI's own session behavior. Hive's answer is not a new agent. It is a coordination layer that leaves the CLIs in place.

The intended user is someone who already has at least one supported agent CLI installed, authenticated, and on PATH. That prerequisite is stated up front, and it is the honest boundary of the product: Hive does not ship a model, an API key, or a fallback agent. If you have never installed Claude Code or Codex, the README points you at the Try Demo wizard instead, which runs a fully client-side preview with a fake orchestrator, two workers, prerecorded scrollback and a prefilled task list. That demo touches neither the server nor a real CLI agent, so it tells you what the workbench looks like without telling you how your own agents behave inside it.

## How the Orchestrator and workers actually run

The mechanism is PTY processes, not simulated roles. According to the README, the Orchestrator is a real agy, claude, codex, opencode, gemini, hermes or qwen process, and the workers are real CLI agents too. Hive runs a local daemon on 127.0.0.1 and serves a browser workbench that attaches to those processes.

The integration point is a shell-level one: Hive injects a small team command into each agent's shell, so an agent can dispatch work, report back, and maintain a shared markdown task graph at <workspace>/.hive/tasks.md. That file is the coordination artifact. Because it is markdown in the workspace, the handoff between agents is inspectable with ordinary tools rather than trapped inside a chat transcript.

This design has a consequence worth stating. Because workers are genuine CLI processes, Hive inherits their behaviour: their authentication, their rate limits, their session semantics, and their failure modes. The README acknowledges this directly in the restart-recovery bullet, which notes that recovery depends on each CLI's native session behavior. Hive coordinates agents; it does not sandbox them or make them deterministic.

## Install Hive and run a first team

Prerequisites are Node.js 22 or newer and at least one supported agent CLI installed, authenticated, and available on PATH. Hive is distributed through npm, and the README explicitly says that if you only want to install or upgrade, prefer the npm commands over building from this repository.

Install globally and start the daemon:

```bash
npm install -g @tt-a1i/hive
hive
```

Hive prints a local URL, usually http://127.0.0.1:3000/. Open it in a browser. If that port is taken, the README gives a flag for a specific port:

```bash
hive --port 4010
```

Upgrades happen in place through the same binary:

```bash
hive update
```

The README states that hive update runs npm install -g @tt-a1i/hive@latest in place, and that any in-flight Hive process must be restarted to pick up the new version. If you installed Hive with pnpm or yarn, upgrade through that same package manager, otherwise the new npm copy will shadow your existing install. When a mirror has not synced the latest release, the README suggests going to the official registry directly:

```bash
npm install -g @tt-a1i/hive@latest --registry=https://registry.npmjs.org
```

During install you may see npm warn allow-scripts or a prebuild-install@7.1.3 deprecated message. The README says these usually come from npm's install-script review plus native binary setup for node-pty, better-sqlite3 and esbuild, and do not mean Hive failed to install. Check whether the command ends with added ... packages before treating them as errors.

The first-run flow has three steps: create a workspace from a project folder, choose an Orchestrator preset, and let Hive create the workspace scaffolding. After that, the README's own examples are the fastest way to see the protocol work. A typical prompt asks for a change with a reviewer in the loop, for example shipping a settings search bugfix with one worker implementing and another reviewing edge cases before the final report. A parallel bug hunt splits a flaky behaviour across workers, one reading the server path, one checking the UI path, one scanning recent commits for regressions. The reports converge in the workbench rather than in separate scrollbacks.

## Platform support and the PWA's real limits

Hive runs on macOS and Linux, with Windows described as best-effort in the README's platform badge. That is a meaningful caveat for teams on mixed machines: the PTY layer is the part of the stack most sensitive to platform differences, and the project does not claim parity there.

The optional PWA install is narrower than it looks. Open http://127.0.0.1:3000/ in Chrome, Edge or Brave and click the install icon in the omnibox. Firefox and Safari do not implement the install-prompt protocol, so the icon only appears in Chromium-based browsers. The daemon must still be running for the app to do anything; if the runtime is unreachable at launch, you get a "Hive runtime is not running" page that auto-reloads once hive is back on 127.0.0.1.

Two details matter in practice. The PWA install scope is keyed by origin, so hive --port 4011 installs as a separate app from hive --port 3000, and uninstalling means visiting chrome://apps and choosing Remove from Chrome. The close-confirmation prompt is also gated by browser policy: if you open the PWA and immediately press Cmd-W or Ctrl-W without clicking or typing first, it closes without asking. The README is explicit that this is browser behaviour, not a Hive bug.

## Where Hive is the wrong tool

The licence is the first constraint. The package declares BUSL-1.1, and the repository carries both LICENSE and LICENSE.BSL. That is a source-available licence, not an OSI-approved open source licence. Anyone whose adoption rules require OSI approval should stop here; no amount of local-first architecture changes that classification.

The second constraint is the dependency posture. Hive is a coordination layer with no agent of its own. If you install it without a supported CLI on PATH, there is nothing for it to orchestrate, and the demo will not close that gap. The README is candid about this, which is why it recommends the demo for people who have not installed an agent yet.

The third is scale-appropriate use. If a single agent already finishes your tasks, adding an Orchestrator and multiple workers adds token spend and process overhead without adding routing value. The README frames Hive around cases where one agent is not enough but a pile of terminal windows is not a workflow; that framing is also its honest limit. And because workers are real CLI processes, a worker that hangs or loses its session is a CLI problem Hive cannot paper over. The README's own restart-recovery bullet puts session behaviour in the CLI's hands.

Finally, the repository and the release channel are not the same artifact. The README states that this repository is Hive's public source baseline and that user-facing releases are distributed through npm. If you need to audit exactly what runs on your machine, that distinction is something you have to resolve yourself, because the README does not document how the published package maps back to this tree.

## Compared with tmux plus a shell script

The obvious alternative is what many people already do: run each CLI in its own tmux pane and drive them with a shell script or a Makefile. That approach is genuinely lighter. It has no Node dependency, no daemon, no browser, and no licence question, and every process stays in a terminal you already understand.

The difference is the routing layer and the shared state. A tmux script can launch four agents, but it has no protocol for one agent to dispatch to another and no shared task graph. Hive's team command and the .hive/tasks.md file are what turn four processes into a team with an inspectable plan. A tmux setup also has no workbench view: worker progress lives in scrollback, which is exactly the problem the README opens with.

That does not make Hive strictly better. A tmux script has no install-time native modules to worry about, and it will keep working on a machine where Node 22 is not available. If your division of labour is fixed and you never need an agent to delegate at runtime, the script is the smaller tool for the job, and Hive's extra machinery buys you a task graph you may not read.

## Maintenance, upgrades and licence cost

The last push to the repository was on 2026-06-18, and the most recent release listed is v0.6.0-alpha.0 from 2026-05-13, while package.json declares version 1.4.0. Those version numbers do not line up, and the README does not explain the gap between the alpha tag and the published package version. Treat the npm package, not the release tag, as the thing you are actually running, and check the CHANGELOG.md in the repository for what changed between them.

Upgrade cost is low by design. hive update reinstalls the latest global package in place, and the README's only operational warning is to restart any in-flight Hive process. The friction is in the package manager: if you installed with pnpm or yarn, upgrading through npm leaves two copies and the npm one wins, which is a confusing failure mode to debug.

On licence, BUSL-1.1 is a business source licence, and the repository also ships NOTICE and TRADEMARK.md files. The practical implication is that the source is readable but the grant is conditional, so the terms that apply to your use are the ones in LICENSE.BSL, not the ones implied by the README's local-first framing. This review cannot tell you whether your use fits those terms.

## Conclusion

Adopt Hive if you already run Claude Code, Codex, Gemini or OpenCode daily and want their work visible in one workspace instead of five terminal tabs; install it with npm install -g @tt-a1i/hive, then run the Try Demo wizard before pointing it at a real repository. Skip it if you need an OSI-approved licence, if you are still on Node 20 or earlier, or if a single agent already finishes your tasks. Before committing, verify three things yourself: that the npm package and the GitHub repository are the same codebase, since the README calls this repository a public source baseline while releases ship through npm; that your chosen agent CLI is authenticated and on PATH, because Hive starts it as a real process rather than emulating it; and that BUSL-1.1 terms fit how you intend to use and redistribute it, which no review can decide for you.

## FAQ

### What companies use Hive?

The README does not name any companies or customers using Hive. It describes the intended user as anyone who already runs CLI agents, and lists example workflows such as shipping a PR with a reviewer in the loop and running a parallel bug hunt, but it gives no adoption list or user figures.

### What do I need installed before Hive will work?

Node.js 22 or newer, plus at least one supported agent CLI installed, authenticated and available on PATH. Hive does not ship an agent of its own, so without a CLI there is nothing for the Orchestrator to run.

### Is Hive open source?

The package declares BUSL-1.1 and the repository carries LICENSE and LICENSE.BSL, so it is source-available rather than OSI-approved open source. The README also describes this repository as Hive's public source baseline, with user-facing releases distributed through npm.

### Which operating systems does Hive support?

The README's platform badge lists macOS and Linux, with Windows marked best-effort. The optional PWA install is narrower still, since the install prompt only appears in Chromium-based browsers such as Chrome, Edge and Brave.

### How do I upgrade Hive to a newer version?

Run hive update, which the README says performs npm install -g @tt-a1i/hive@latest in place, then restart any in-flight Hive process. If you installed with pnpm or yarn, upgrade through that same package manager so the npm copy does not shadow it.

## Sources

- [Issues](https://github.com/tt-a1i/hive/issues)
- [Project website](https://hivehq.dev)
- [README](https://github.com/tt-a1i/hive/blob/main/README.md)
- [Releases](https://github.com/tt-a1i/hive/releases)
- [tt-a1i/hive on GitHub](https://github.com/tt-a1i/hive)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tt-a1i-hive
