name: hermes-agent
description: Autonomous AI agent with 60+ built-in tools and 20+ platform integrations
snapcraft: hermes-snap/snap/snapcraft.yaml at main · kenvandine/hermes-snap · GitHub
upstream: GitHub - NousResearch/hermes-agent: The agent that grows with you · GitHub
upstream-relation: I only maintain the snap packaging. I am not involved with NousResearch or the upstream project.
supported-category: agent/assistant that runs arbitrary user-directed code and needs to reach files and programs that aren’t known at build time (same bucket as shells and coding assistants).
reasoning:
hermes-agent is an autonomous agent with 60+ built-in tools (browsing, browser automation, code execution, file operations, scheduled jobs) that also writes new skills for itself over time. It bundles a Python runtime and a Chromium build. The set of files and programs it touches isn’t fixed; it grows as the user adds skills and points it at new tasks.
That growth is exactly why strict confinement can’t hold it. I have no way to enumerate ahead of time which paths it’ll read or which binaries it’ll run, and the auto-generated skills make that set open by design. Testing under strict with snappy-debug gives denials that never converge. home/system-files/personal-files don’t cover arbitrary paths, and nothing allows arbitrary execve, so there’s no interface answer here.
It’s therefore published as classic.
On isolation: classic means the agent can do whatever the person running it can do. Because of that, the docs recommend installing and running it inside an LXD container rather than directly on the host. That keeps the broad access inside a boundary the user sets up themselves (throwaway filesystem, limited network, nothing reaching the rest of their data), while the agent can still use whatever tools and files it needs inside that container. Strict confinement would just break the agent and give weaker guarantees than containing it properly anyway.