name: picoclaw
description: Tiny, fast, local-first personal AI assistant
snapcraft: picoclaw-snap/snap/snapcraft.yaml at main · kenvandine/picoclaw-snap · GitHub
upstream-relation: I only maintain the snap packaging. I am not involved with Sipeed 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:
picoclaw is a single static Go binary meant for very small hardware, but it’s a real agent: code execution, file operations, scheduled jobs, MCP servers, and connections to whatever LLM provider and messaging platforms the user picks. The footprint is tiny; the access it needs is not.
Like the other agents, what it opens and runs is the user’s call at runtime, not something I can list when building the snap. Strict confinement produces an unbounded run of snappy-debug denials with no fixed allow-list that resolves them, because the filesystem interfaces can’t cover arbitrary paths and nothing grants arbitrary execve of host tools.
That’s why it’s 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.