A 152 MB host coordinates isolated agent containers
NanoClaw puts a personal assistant behind the messaging tools people already check. A Node host receives a message, maps the sender and conversation to an agent group, writes work to SQLite, and wakes that group's container. The runner calls a model, uses approved tools, and returns a response through another database. Each group can have its own instructions, memory, workspace mounts, skills, MCP tools, and provider. That is a useful boundary when one assistant handles family chat while another touches source code.
Our checkout contained 875 files and about 115,729 lines of source, much more than the README's informal description of a handful of files. It is still understandable as one host process plus short-lived or persistent agent containers, rather than a cluster of services. The trade is visible: every channel adapter, model route, mount, credential rule, delivery path, and scheduled task becomes part of the installation you operate.
Docker limits file access, while mounts decide the real boundary
The security idea is concrete. Agent commands run inside Linux containers, and only explicitly mounted paths appear inside each workspace. Raw API keys stay in OneCLI's Agent Vault; outbound requests receive credentials at the gateway according to policy and rate limits. Separate agent groups can keep their files and memories apart. This is stronger than asking one large process to respect an internal allowlist.
Isolation still depends on operator choices. NanoClaw's v2.3.0 release added admission checks around container specifications and stopped allowing credential values in container environment variables. Open issue 3532 reports a narrower policy gap: a tool scoped to selected existing agents may be available to a group created later because its new gateway identity has no copied block rules. Review newly created groups, mounts, host patterns, and secret grants before letting them accept messages.
What happened when we ran it
Our sandbox installed 242 pnpm packages in 19 seconds and occupied 152 MB. The build completed successfully in 13 seconds. We ran commit 6137e0e inside an unprivileged Node 22 container with 3 CPUs, 8 GB of RAM, and no secrets. The repository is a workspace monorepo with 7 CI workflow files and no root Dockerfile or tests directory.
The test command failed after 762 seconds. Vitest reported 1,949 passed and 95 failed out of 2,044 tests, spread across 14 failed and 146 passed test files. The log tail repeated Test timed out in 5000ms and named a recurrence test concerning script-failure backoff. It does not show why those cases timed out, so we cannot attribute them to Docker, CPU limits, or a particular dependency. The only safe conclusion is that this checkout did not pass its full suite in our stated sandbox.
Setup installs an operating model, not only dependencies
The quick-start script checks or installs Node, pnpm, and Docker, registers a model credential with OneCLI, builds an agent image, and pairs the first channel. When deterministic setup cannot continue, it invokes Claude Code to diagnose the machine and resume. That can be convenient for an experienced owner who reviews proposed changes. It is a poor control surface for a team that expects a repeatable installer with every decision captured in configuration.
Version 2.3.0 requires Node 22 or newer and carries migration work for customized source, Slack installations, database access, and the container driver boundary. An open macOS report narrows one better-sqlite3 crash to Node releases before 22.14.0 even though the declared floor accepts them. Check the patch version, build the agent image, pair a disposable channel, and test restart behavior before installing a background service on the host.
Code changes replace a conventional settings screen
NanoClaw deliberately asks users to keep a fork. Channels and alternative providers arrive through Claude Code skills that copy selected modules and dependencies into that fork. Behavior changes are also code changes: the README suggests asking Claude Code to alter trigger words, memory, replies, or recurring behavior. This keeps unused adapters out of the running tree and makes the result personal, but it moves configuration into source control and upgrades.
Open issue 3529 shows the maintenance cost. Its reporter says the update skill rejected a locally written channel adapter because no matching skill existed, and overwrote a customized Matrix adapter with the registry copy. The report includes a workaround, not a stable opt-out contract. Anyone adopting the fork model should commit local changes, inspect update diffs, and maintain a small regression set for every channel or provider they alter.
Messaging needs duplicate and failure checks
Chat delivery has more than one route because an agent can emit normal result text or call an MCP message tool. Open issue 2404 says using both for the same content can deliver that message twice. Another open report, issue 3457, describes retries hitting a SQLite unique constraint after a message had already landed. Both have specific proposed fixes, and recent pull requests show maintainers working on delivery behavior. Neither report supports assuming every installed channel is affected in all cases.
GitHub listed 992 open issues and pull requests and 30,625 stars when fetched on August 26, 2026. The repository was pushed the same day, two days after v2.3.0, so this is active software with a fast-moving queue rather than an abandoned experiment. Use an expendable chat first. Send duplicate-sensitive prompts, stop the host mid-turn, restart it, force a provider error, and verify what the recipient sees before assigning a scheduled job that can send mail or change files.