name: nullclaw
description: Lightweight local-first autonomous AI assistant
snapcraft: nullclaw-snap/snap/snapcraft.yaml at main · kenvandine/nullclaw-snap · GitHub
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:
nullclaw is a tiny static binary, but it’s a full agent: it works against the user’s local model servers (Lemonade, Ollama), edits files in their workspace, runs commands, and schedules jobs. Small footprint, but the things it reaches are the user’s, not mine.
Strict confinement doesn’t work here for the same reason it wouldn’t for a shell. What it opens and what it executes is decided at runtime by the user, so there’s no fixed interface set that covers it. Under strict, snappy-debug just produces a steady stream of denials for new paths and programs with no end state to allow. The filesystem interfaces can’t express arbitrary absolute paths, and there’s no interface for running arbitrary host binaries, which is the whole point of the tool.
That’s why 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.