| Filename | Latest commit message | Latest commit date |
|---|---|---|
84d4808d54
The subagent daemon now reads the parent agent's runtime at startup (`hive_runtime::RuntimeSpec`, from the harness's `HIVE_RUNTIME` / `HIVE_ACP_*`, which `mcp.nix` forwards onto its unit). On claude nothing changes. On ACP, each run drives an `AcpRuntime` whose session id is kept per name under the harness dir: `start` archives the old one, `continue` loads it (and fails when none is recorded), `interrupt` sends `session/cancel`, a role goes in front of the first prompt, and permission requests get the answers a claude subagent's tool list gives. The unit loads `backendEnvironmentFile` on ACP only, so the agent can authenticate. The end-of-turn handling moves out of the claude loop into `after_turn` unchanged, so both loops share it. Refs #4391 |
||
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
hive-subagent-mcp
Per-agent daemon (hive-subagent-daemon) that spawns nested headless
claude sessions on request and serves the tool surface
(start/continue/status/interrupt, plus a separate
subagent-facing goal_reached/need_help route, one per-session URL)
directly over streamable-http. No stdio bridge, no per-turn respawn — an
agent's claude reconnects to the same stable URL every turn.
Independent of hive-bash-mcp — a subagent spawns a full nested
claude session, a much heavier capability than a bash command, worth
its own deployable/restartable unit.
Shape
One bin (hive-subagent-daemon, src/main.rs) built from the crate's
own lib (src/lib.rs):
session.rs— the actual claude-facing logic:Claude::spawn+RunningClaude::wait/cancel_handle(notInfiniteSession::run, which has no cancel handle to reach in — see the module doc for the v1 scope this trades away), the turn-continuation loop agoalswitches on, and the in-memory maps that are the only state this daemon keeps (no task files — a restart stops whatever's running; the actual claude session is the durable store, found again by name viahive_claude::SessionStore).mcp.rs— thermcptool routers (the parent'sstart/continue/status/interrupton/mcp, the subagent'sgoal_reached/need_helpon/signal/mcp/<token>) +serve_http. Neither signal tool takes a session name: the token in the path is minted per run and resolved to a session before dispatch, so a subagent has no way to name — and therefore no way to signal — a sibling. One route with a path parameter, because theRouteris built once at startup and sessions come and go for the daemon's whole life.paths.rs— the in-agent todo-socket path.