| Filename | Latest commit message | Latest commit date |
|---|---|---|
hive-c0re pushes todos into each agent over the in-agent socket, and every one of those dials has been failing with EACCES. The socket is created by todo_server::bind with no mode set at all, so it lands at 0777 & ~umask -- typically 0755. connect(2) on a unix socket requires *write* permission, and hive-core is neither the socket's owner nor in its group, so it is locked out. The tell is the sibling socket. web.sock is bound in the same directory, by the same process, as the same user, and does set its mode (0666) immediately after bind. Only the socket missing that call fails, which is also why no ownership or chown theory explained it: both sockets share every directory they live in, so anything at the directory level would have broken them together. Fix is the two lines web.sock already had. Access control for these sockets is the containing directory's job, not the socket's -- the mode here only has to not exclude the host daemon that is supposed to reach it. Observable effect: scheduled prompts and message wakes reach agents again. An agent whose wake is dropped still sees its messages whenever something else wakes it, so the failure presents as agents that look healthy but answer late, or not at all if nothing else is waking them. |
||
| .. | ||
| prompts | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
hive-agent
The in-container harness serve-loop binary — one instance per agent.
Long-polls the broker inbox and drives one claude --print turn per
inbox message, over the hive-claude driver. There is one role here
(agent); the Surface trait + AgentSurface zero-sized type tag keep
the turn loop generic and testable for future roles without a
parallel copy of the loop.
When to use it
You don't call into this crate from elsewhere — it's the top-level
binary systemd starts per agent container. Look here when you need to
understand or change: what happens between "a message lands in the
inbox" and "claude produces a reply", how login/auth is bootstrapped,
how the per-agent web UI is served, or how turn/event stats get
recorded. Architecture detail lives in
docs/turn-loop/; this README is just the
map of the module tree.
Shape
turn.rs— the turn-loop policy layer: renders the system prompt + MCP config, invokeshive-claude, classifies the outcome, and feeds the event/turn-stats sinks.client.rs— broker client (inbox poll, ack, send) speaking thehive-sh4rewire protocol.login.rs/login_session.rs— first-run and session-resume auth flow for theclaudeCLI.mcp_config.rs— renders the per-turn--mcp-config/--allowedToolsblob from tool groups + capabilities.todos.rs/reminders.rs/todo_server.rs— the harness-local loose-ends v2 stores (sqlite-backed) and the in-agent socket server extra MCP daemons +hive-agent-mcpdial into for todo/reminder ops.vacuum.rs— periodic sqlite vacuum sweep for the harness-local stores.events.rs/turn_stats.rs/stats.rs— append-only event sink and per-turn telemetry recording (context usage, cost, tool favorites) underharness/.forge_notify.rs— subscribes to forge notifications and wakes the harness on new activity.prompt.rs— system-prompt renderer (persona + tool docs + environment facts).web_ui/— the per-agent dashboard (terminal pane, status, schedules) served over the built-inhive-agentweb port.paths.rs— canonical path resolution for state/harness dirs and the harness-local sqlite files.
Sibling: hive-agent-mcp (the MCP server this loop points claude
at every turn). Both are described together in
docs/turn-loop/::Harness binary shape.