vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Activity
hyperhive/hive-runtime
History
Repository files (latest commit first)
Filename Latest commit message Latest commit date
atlas a2ab40cc69 hive-runtime: record a new ACP session only once its first prompt is answered 
The session id was written to the session file right after session/new,
but the system prompt rides on the first prompt only. If that prompt
failed, the next turn (or the next harness start) resumed the recorded
session as not-new and the system prompt never reached it.

The id is now written after the first session/prompt gets its reply.
A failed first prompt leaves nothing recorded, so the next turn starts
a new session and sends the system prompt again. Chosen over a separate
"system prompt delivered" marker: one file, and "recorded" already means
"usable".

Tests drive AcpRuntime against a scripted sh agent that fails the first
prompt: in-process and across a restart, the retry is a new session
carrying the system prompt.

Also: PermissionPolicy now sees a PermissionAsk (kind plus the MCP
server the tool belongs to, matched by name against the servers handed
to the session), so a caller can tell MCP tool calls from other `other`
requests.

Refs #4391
2026-09-29 22:29:36 +02:00
..
src hive-runtime: record a new ACP session only once its first prompt is answered 2026-09-29 22:29:36 +02:00
Cargo.toml hive-runtime: record a new ACP session only once its first prompt is answered 2026-09-29 22:29:36 +02:00
README.md hive-runtime: shared runtime crate with claude and acp backends 2026-09-29 22:29:36 +02:00

README.md

hive-runtime

The layer an agent's turns are driven through: one Runtime interface (run, compact, archive) with a backend per runtime.

  • claude — claude --print through the hive-claude crate's InfiniteSession. A pass-through: same spawn, same session handling, same errors.
  • acp — any Agent Client Protocol agent, spawned from a command, args and env handed to it (RuntimeSpec, read from HIVE_RUNTIME / HIVE_ACP_COMMAND / HIVE_ACP_ARGS / HIVE_ACP_ENV). It knows no agent by name; which agent runs, and how it is configured, is decided in nix (services.hyperhive.agent.runtime, services.hyperhive.agent.acp.*).

Both backends report a turn through hive_claude::Sink in claude's stream-json shape. The ACP backend translates session/update notifications into it (text and thought chunks as whole blocks, tool calls as tool_use + tool_result, MCP tools named mcp__<server>__<tool>), so the harness's stream consumers read either backend unchanged. Context usage comes from ACP usage_update.

The crate depends on no hyperhive binary crate, so hive-agent and hive-subagent-mcp can both drive turns through it.

ACP backend: what it needs from the agent

  • mcpCapabilities.http in its initialize response. The hyperhive tools are only served over HTTP, so an agent without it is refused at startup.
  • loadSession, to pick its session back up after a harness restart. Without it every restart starts a new session.

ACP backend: not yet

compact returns Error::Unsupported, there is no cancel, and no idle watchdog (Config::idle_timeout is ignored). An agent that retries a failing provider on its own keeps the turn open until it gives up.