| Filename | Latest commit message | Latest commit date |
|---|---|---|
The comments and docs around the empty-`--tools` assert stated a mechanism: that an empty value parses as *unset* and therefore grants MORE built-ins than omitting the flag. That claim came from a measurement, and the installed `claude --help` (2.1.268) says the opposite in as many words — `Use "" to disable all tools`. One of the two is wrong and this repo is not the place that settles it. The rule the code enforces is right under both readings, which is precisely why it should not be argued from either: we never emit an empty `--tools`, because what an empty one means is release-dependent and nothing here wants a subagent with no built-in tools regardless. So the prose now states the rule and the ambiguity, and asserts nothing about `""` in either direction — replacing the claim with its opposite would be the same mistake sourced differently. No behaviour change: the assert, the resolution and every test are untouched. Two test comments also gained the limit they were quietly missing. `no_spawned_tool_escapes_the_session` hardcodes ten names, so it is a canary for tools someone thought to list, not a guarantee — the guarantee is the subset property, which covers tools nobody has invented yet. And `a_subagent_gets_no_builtin_its_parent_lacks` resolves both sides in one process off one env var, so it catches a code divergence but not the two real systemd units disagreeing about `HIVE_TOOL_GROUPS` — which is what they did until the previous commit, and is not a thing a unit test can reach. Refs #4416 |
||
| .. | ||
| bash.md | ||
| forge-cli.md | ||
| forge.md | ||
| hivectl-cli.md | ||
| hivectl.md | ||
| lifecycle.md | ||
| matrix.md | ||
| README.md | ||
| scheduling.md | ||
| subagent.md | ||
| swarmctl-cli.md | ||
Tools
hivectl is your tool — the operator's own host CLI. Everything
else here documents the tool surface your agents get inside their
containers (the MCP tools an agent's own claude session can call).
You never call these directly, but they're the reference for what an
agent can actually do — useful when you're trying to understand or
debug agent behavior.
For the operator
- hivectl — the curated guide: provisioning forge and matrix accounts, gateway htpasswd management, container lifecycle shortcuts, interactive agent shell access.
- hivectl-cli — the exhaustive, autogenerated flag-by-flag reference, kept in lockstep with the binary by CI.
For the swarm operator
- swarmctl-cli — the exhaustive, autogenerated
flag-by-flag reference for
swarmctl, kept in lockstep with the binary by CI the same wayhivectl-cli.mdis.swarmctlitself runs as root on the swarm-controller host, not throughhivectl— seeswarmctl/README.mdfor why. Two verb families today:user(authelia's subject store, edited in place) andagent create(queues the swarm-controller's creation job graph). No curated guide yet; add one here if/when that grows.
What your agents can do
- bash — background shell execution (
mcp__bash__*), available on every agent unconditionally. - subagent — spawn nested headless claude sessions
(
mcp__subagent__{start,continue,status,interrupt}), shipped default-on for every agent today alongsidebash(expected to become a real opt-in capability later). - forge — the
hive-forgeForgejo CLI every agent has for issues, PRs, and comments. Not an MCP tool — a binary agents shell out to instead of ad-hoc curl. - forge-cli — the exhaustive, autogenerated
flag-by-flag reference for
hive-forge, kept in lockstep with the binary by CI the same wayhivectl-cli.mdis. - lifecycle — kill/start/restart/update for the agents in a caller's own subtree, plus the approval-gated config-change tools.
- matrix — the matrix MCP tool surface
(
mcp__matrix__*) for agents with a matrix account, multiple accounts per agent, and declaring extra MCP servers generally. - scheduling — scheduled prompts (operator
approval required) and the diagnostics tools (
get_logs,get_host_journal).