
Beadhive
io.github.beadhivev0.24.1更新于 Oct 9, 2026
Manage cross-repository beads work, hive status, and Beadhive workflows through bh-mcp.
概览
让助手通过 bh-mcp 服务器管理跨仓库的 beads 问题跟踪、hive 状态和 Beadhive 工作流。
- 功能
- Beadhive(bh)是一个 CLI,用于跨多个仓库编排 beads 问题跟踪,每个仓库都是自己的 beads 数据库,称为 hive,并带有简短稳定的前缀。它可以接入仓库、保持标签一致、在一个或全部 hive 上运行 bd 和 git 命令,并把所有 hive 聚合为一个跨仓库视图,即使代码未检出也可以。bh-mcp 服务器把这些工作、hive 状态和 Beadhive 工作流暴露给助手。
- 适用场景
- 当助手需要处理分布在多个仓库中的 beads 问题跟踪、查看 hive 状态,或从单一跨仓库视图驱动 Beadhive 工作流时使用。它适合已经使用 Beadhive CLI 及其约定的团队。
- 运行要求
- 作为本地进程在用户机器上运行(仅桌面端,stdio 传输),从 PyPI 安装为 beadhive,并用 uvx 运行。它是 bd、git、git-workspace、dolt 和 docker 之上的轻量编排器,因此这些工具必须存在;推荐的受管路径使用 nix 对它们进行版本固定。配置和运行时状态位于 ~/.beadhive/ 下。未声明认证、环境变量或请求头。
安装
在 SourceWeft 中
- 打开 控制台中的 Beadhive,将其添加到工作区。
- 为需要使用其工具的对话启用该服务。
Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。
其他 MCP 客户端
参照 仓库 中的启动说明。
README
Beadhive (bh)
[PyPI version] [Python versions] [GitHub tag] [License: MIT] [GitHits index status] [Ask DeepWiki]
bh is a single CLI for managing beads issue tracking across many repositories. Each
repo is its own beads database (a hive) with a short, stable prefix; bh onboards them,
keeps their labels consistent, runs bd/git across one or all of them, and aggregates
every hive into one cross-repo view — even hives whose code isn't checked out.
It's a thin orchestrator over bd, git, git-workspace, dolt, and docker: bh
encodes the conventions, the registry, validation, and routing. Config and runtime state live
under ~/.beadhive/; no issue data lives there — each hive's issues live in its own Dolt
DB under refs/dolt/data on that repo's own git remote.
bh is the CLI of Beadhive, a bead-machine — a software factory that uses beads.
The process it drives is documented in docs/AGF.md.
This repo is the CLI's source (Python package beadhive on PyPI, command bh). For what
Beadhive is conceptually, rather than how to drive it, see beadhive.ai.
Install
Agents: point your agent at INSTALL.md — the preferred install path. It
carries a structured install: frontmatter block (the agent reads it, discloses the plan,
and asks before each command) plus a prose fallback any agent or human can follow.
Doing it by hand? There are two routes, in this order.
Managed path (recommended)
bh doesn't work alone — it drives bd, dolt, gh and git-workspace. This is the only
route that installs and version-pins all of them with it, from flake.lock:
--force and that third line are both load-bearing, not decoration: unforced, uv tool install no-ops on a machine that already has bh and still exits 0. Measured on macOS
with 0.7.1 installed, it reported "Installed 2 executables: bh, bh-mcp" and bh --version
still said 0.7.1. This step is done when the version is right, not when the install exits 0.
latest is a release channel branch, not a version: CI moves it onto each release's commit
once that release publishes, so this line never carries a version and never needs a release-day
edit. Don't shorten it to github:beadhive/beadhive#default — that resolves the default
branch, which is not the latest release.
The one precondition is nix, which needs root — a system daemon, and an APFS volume on macOS.
INSTALL.md carries the one-time installer, the ~130s
/ 2–3 GB cold cost, the platform limits (macOS: Apple Silicon only) and the nix ≥ 2.30 that
nix profile add needs.
PyPI route (fallback, not recommended)
For machines where you can't install nix, or won't. It works, and it's genuinely one command
— but it installs bh alone, leaving the other four tools to whatever the machine happens
to have, including a bd you then install from HEAD by hand:
See INSTALL.md for what that leaves you to keep
matched by hand, and for the Docker route.
First run — rung 1
One laptop, local-only. From a fresh install to a ready list:
Run bh setup guide to finish setup — a guided, probe-first walk from a bare install to a
configured workspace. It covers the sequence above plus the parts that aren't one command
(orgs, providers, git-workspace), checking each step's state before it acts, so it is also
safe on a machine that is already half-configured. Reach for it if you installed via
brew, pip or a copy-pasted command and never saw INSTALL.md.
What that costs: HQ is local — no backup, and no second machine yet. That's the posture,
not an omission; wiring a remote is rung 2. See docs/ADOPTION.md for the
four rungs, what each buys, and what staying on this one costs.
Agent harnesses
bh furnishes seats for Claude Code (--claude) and OpenCode (--opencode) —
pass either to bh hive onboard <provider>/<org>/<repo>. docs/AGF.md carries the
per-harness support matrix, including what does and
doesn't apply for codex. On Claude Code, the bh claude-plugin vends the seat agent defs
and role skills:
Going further
One line each, and who it's for:
-
docs/MCP-PUBLISHING.md— MCP registry and directory upkeep. -
Context7 — library documentation for agents.
-
docs/ADOPTION.md— it works; what's the next rung? The four rungs, what each buys, and what staying on yours costs. -
INSTALL.md— picking a route. Managed path, PyPI and Docker, and the tradeoffs between them. -
docs/ONBOARDING.md— fresh machine, step by step. Zero to a configured AGF workspace with registered hives. -
docs/UPGRADING.md— moving between versions, or between routes. -
docs/HQ.md— Factory HQ. What it is and what it stores. -
docs/OPERATOR-UI.md— first local operator UI. Start and troubleshoot the loopback-only, unauthenticated, read-only profile. -
docs/COMPLEXITY-ROUTING.md— capability-first dispatch. Complexity labels, late-bound model selection, availability, and migration recovery. -
docs/HIVES.mdand the multi-host ADR — more than one host. Hive kinds, leases, and host roles. -
beadhive.ai — what Beadhive is, conceptually, if you want the shape before the commands.
-
docs/OVERVIEW.md— everything else. Design and reasoning, configuration, the full command surface, component by component.
Questions / feedback
General questions, feedback, and bug reports go through
GitHub Issues. For security vulnerabilities,
see SECURITY.md instead of filing a public issue.
Develop
Developing bh itself
You don't need any of this to use bh — it's for working on the CLI's own source.
just install and just build stamp the artifact with a PEP 440 local
segment — 0.11.5+local.g790ef0d, plus .dirty when the checkout had
uncommitted changes — so bh --version distinguishes your build from the
release it was built from, and the wheel filename says what is under test. PyPI
forbids local segments, so a local build can never be published by accident;
just build-release is the deliberate opt-out that produces a publishable
artifact (and is what CI runs on a v* tag).
See CONTRIBUTING.md for the plain-git contributor path — setup, tests,
and how to submit a change.
Collapsed on purpose, not by oversight. It pairs with "Manual install" on beadhive.ai: both are real content that simply isn't what most readers came for, so it is disclosed rather than deleted. Please leave it closed.
来源:README.md,提交 898aa62
工具
0版本历史
1- v0.24.1最新Oct 9, 2026


