name: zeroclaw
description: Zero-config autonomous AI agent
snapcraft: zeroclaw-snap/snap/snapcraft.yaml at main · kenvandine/zeroclaw-snap · GitHub
upstream: https://github.com/clawrun-sh/clawrun
upstream-relation: I only maintain the snap packaging. I am not involved with 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:
zeroclaw wraps a native agent runtime and exposes a gateway (HTTP/WebSocket) for chat and agentic tasks. What it runs and reads is driven by whatever flows the user connects and the prompts they send, so it ends up touching arbitrary files and host programs.
I can’t predict any of that at build time, which is what rules out strict confinement. There’s no interface set that means “run anything and read anything the user asks”, and snappy-debug under strict just keeps reporting fresh denials. The available filesystem interfaces can’t enumerate arbitrary paths and none grant arbitrary execve, both of which the agent relies on.
So it ships 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.