| Filename | Latest commit message | Latest commit date |
|---|---|---|
`services.hyperhive.agent.matrix.enable` was a second source of truth for a fact the account set already carried: after ①-③ the hive-internal `main` account is an ordinary `matrixAccounts` entry, so "does this agent have matrix" and "does this agent have an account" were the same question asked twice, with the boolean able to disagree. The option is gone and a non-empty `matrixAccounts` now gates the daemon unit, its token path-watcher and the injected `extraMcpServers.matrix` entry. That is only a real condition because `matrixAccounts.main` is itself gated: it is declared when `matrix.url != null`, never unconditionally. A `main` with no homeserver is an account the daemon can never log in as, so declaring one always would have made the signal trivially true and turned matrix on for every agent in every hive. With the URL gate, the empty set is reachable exactly for an agent the hive gave no homeserver and whose operator declared no account of its own — the state the old `enable = false` expressed. Assertions: "extras require enable" is deleted, having become the definition of the thing it checked (an external-only account with its own homeserver is now rendered rather than rejected). `main.tokenFile` stays pinned, re-guarded on `? main` instead of on the flag, since `main` is absent whenever the URL is null and an unguarded index would throw there. Both spellings of the option get `mkRemovedOptionModule`, following ../host-modules/deploy.nix's registrationTokenFile pair rather than a silent delete: the definition whose meaning changes is `false`, and left undeclared it would be ignored and hand the agent the tools its operator turned off. Failing the eval with the replacement spelling is the only outcome that cannot. module-eval gains the three arms — URL, nothing, external-only — with the middle one carrying why it exists: it is the only thing in the suite that would notice `main` becoming unconditional again. Refs #4475 |
||
| .. | ||
| bash.md | ||
| forge-cli.md | ||
| forge.md | ||
| hivectl-cli.md | ||
| hivectl.md | ||
| lifecycle.md | ||
| matrix.md | ||
| README.md | ||
| scheduling.md | ||
| subagent.md | ||
| swarm-logs-cli.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).