Daemon silently disables managed skills when sandbox dependencies (ripgrep, socat) are missing

[Poytr1]

This was generated by AI during triage.

Summary

On a host without ripgrep and socat, the daemon's skill install fails on every reconcile and clears all previously managed skills. The failure is a WARN in the daemon log only: the console shows nothing, the runtime probe reports the runtime as fully healthy, and the agent keeps serving requests without its managed skills.

These two binaries do not appear to be documented as daemon-host prerequisites. README.md lists Node >= 24.12.0, pnpm 11, and Docker, all of which are framed as development requirements.

Environment

• Deployment: self-hosted Docker Compose, default no-auth loopback mode
• Images: ghcr.io/agentconnect-md/{control-plane,web,relay}:latest (pulled 2026-08-14)
• Daemon: @agentconnect.md/daemon 1.40.0, run natively via npx (not in Compose)
• Host: Ubuntu 24.04, Linux 6.17.0-1008-gcp, Node v26.5.0
• Runtimes present: claude-acp (@agentclientprotocol/claude-agent-acp v0.67.0), codex-acp (@agentconnect.md/codex-acp v1.9-agentconnect.1)

Steps to reproduce

1. Provision a host that has a supported ACP runtime on PATH, but no ripgrep and no socat.
2. Start the daemon and connect it to the Control Plane.
3. Create an agent placed on that daemon and send it any message.

Actual behaviour

The daemon logs this on every reconcile that launches an agent host:

[agentconnect] WARN  skills: unified install failed; clearing previously managed skills
(skills CLI exited with status 1: agentconnect sandbox-runtime:
  Sandbox dependencies not available: ripgrep (rg) not found, socat not installed)

Meanwhile, the same daemon reports everything as healthy:

[agentconnect] INFO  runtimes ready: claude-acp, codex-acp
[agentconnect] INFO  probe: claude-acp ok (@agentclientprotocol/claude-agent-acp v0.67.0, models: default, opus[1m], claude-fable-5[1m], sonnet, haiku)
[agentconnect] INFO  probe: sweep complete — 2/2 runtime(s) reachable

GET /api/v1/orgs/:orgId/daemons also reports "status": "ready" and "health": "ok".

Nothing in the console indicates that managed skills are unavailable for agents on this daemon.

Expected behaviour

Any of the following would make the failure visible immediately:

1. Preflight at daemon start. The daemon already probes runtimes at startup and prints a runtimes not installed (skipped): … line. Sandbox dependencies deserve the same treatment, for example: sandbox dependencies missing: ripgrep, socat — managed skills will be unavailable.
2. Surface it in the console. Daemon health is ok while a whole subsystem is degraded. A degraded/warning health state, or a badge on the daemon and its agents, would make this visible to someone who never reads daemon logs.
3. Document the prerequisites. List ripgrep and socat as daemon-host prerequisites wherever the daemon connect command is provided, ideally including the console's “add daemon” dialog.

Notes

The documentation gap cost the most diagnosis time. rg was defined as a shell function in the operator's interactive shell, so command -v rg succeeded when checked manually while the daemon's own PATH had no such binary. A clean-environment check exposed the mismatch:

env -i PATH=/home/linuxbrew/.linuxbrew/bin:/usr/local/bin:/usr/bin:/bin \
  sh -c 'command -v rg || echo "rg NOT on daemon PATH"'

rg NOT on daemon PATH

Installing both packages resolved the warning. A startup preflight that reports the daemon's own view of PATH would have made this unambiguous.