NanoClaw: a container-isolated personal AI assistant you fork instead of configure

What NanoClaw solves, and who it is written for

The README states the motivation directly: the author wanted the core functionality of OpenClaw without giving software he did not understand full access to his life. The stated comparison is size and isolation. OpenClaw is described as nearly half a million lines of code, 53 config files and 70+ dependencies, with security enforced at the application level through allowlists and pairing codes, everything running in one Node process with shared memory. NanoClaw answers with one process, a handful of files, and agents that run in their own Linux containers with filesystem isolation rather than behind permission checks.

That framing defines the audience. This is not a platform for a team that wants to deploy one shared assistant for an organization. The README says the project is built for the individual user and describes it as bespoke software: you make your own fork and have Claude Code modify it. The intended reader is comfortable with Node, Docker and the command line, and would rather read a small codebase than learn a configuration language.

How the isolation and agent model actually fit together

Each agent group gets its own CLAUDE.md, its own memory, its own container and only the mounts you explicitly allow. The README's phrasing is that nothing crosses the boundary unless you wire it to. Bash access inside an agent is therefore not the same risk as bash on your host, because commands execute inside the container.

Channel topology is a separate decision from agent topology. The README describes three arrangements: one channel per agent for full privacy, one agent shared across many channels for unified memory with separate conversations, or several channels folded into a single shared session so one conversation spans multiple surfaces. The choice is made per channel through /manage-channels, and docs/isolation-model.md is cited as the reference.

Credentials follow a different path. Agents never hold raw API keys. Outbound requests route through OneCLI's Agent Vault, which injects credentials at request time. The dependency list confirms the integration: @onecli-sh/sdk is pinned at 2.2.1 in package.json. Scheduled tasks are executed by the agent, and the README mentions optional script gates that avoid waking the agent when there is no work, documented in docs/scheduled-tasks.md.

The design consequence worth naming: because isolation is per container and mounts are explicit, adding a capability usually means editing mounts or copying a module into your fork, not toggling a setting.

Installing NanoClaw and pairing a first channel

The README's quick start is three commands. The script handles the bootstrap: it installs Node, pnpm and Docker if they are missing, registers your Anthropic credential with OneCLI, builds the agent container, and pairs your first channel. Slack, Telegram, Discord, WhatsApp, iMessage and a local CLI are the options named in the README.

git clone https://github.com/nanocoai/nanoclaw.git nanoclaw-v2
cd nanoclaw-v2
bash nanoclaw.sh

Expect an interactive walkthrough rather than a silent install. If a step fails, the README states that Claude Code is invoked automatically to diagnose the problem and resume from where it broke. That hybrid is deliberate: the scripted path is fast and deterministic, and control hands off to Claude Code when a step needs judgment.

Channels beyond the first are not enabled by configuration. The README describes a skill model where you run a slash command and the skill copies exactly the module you need into your fork. For Telegram that means /add-telegram, and the same pattern covers Discord, Slack, WhatsApp and the rest.

/add-telegram

Alternative model providers follow the same pattern. /add-codex brings in OpenAI's Codex through a ChatGPT subscription or an API key, /add-opencode covers OpenRouter, Google and DeepSeek, and /add-ollama-provider targets local open-weight models. The README states provider is configurable per agent group.

If you are moving from version 1, the migration path is a separate script run from a fresh checkout beside the old install. It merges .env, seeds the v2 database from registered_groups, copies group folders, session data and scheduled tasks, installs the channel adapters you select, copies channel auth state including the Baileys keystore for WhatsApp, and builds the agent container. It does not flip the system service; you choose "switch to v2" at the prompt or do it manually after testing, and the v1 install is left untouched.

git clone https://github.com/nanocoai/nanoclaw.git nanoclaw-v2
cd nanoclaw-v2
bash migrate-v2.sh

The README warns to run that script directly, not from inside a Claude session, because the deterministic side needs interactive prompts and real shell I/O for the Node and pnpm bootstrap, Docker, OneCLI and the container build.

The customization model is also the main limitation

Customization equals code changes. The README presents this as a virtue: no configuration sprawl, and a codebase small enough that editing it is safe. It is also the sharpest constraint in the project. If you want behavior the trunk does not ship, the answer is to modify your fork, which means you now own a divergence and carry the cost of rebasing it against future releases.

The skill model softens this at the edges. Channel adapters live on a long-lived channels branch and alternative providers on a providers branch, and the /add-<channel> skills copy the modules you need. But the README is explicit that trunk ships the registry and infrastructure, not specific adapters. So a channel that has no skill is not available by editing a config file.

Two more boundaries are worth stating plainly. Container isolation is listed as supported on macOS, Linux and WSL2, so native Windows is not a target. And there is no monitoring dashboard or debugging UI: the README says that beyond setup you describe the problem in chat and Claude Code handles it. If your team's operations model depends on a status page or a metrics endpoint, this project does not offer one.

The migration documentation is also incomplete on rollback. The README describes what migrate-v2.sh does and does not do, and notes that v1 is left untouched, but it does not document a supported rollback procedure for the v2 side once you have switched the system service.

NanoClaw against OpenClaw: same job, different security boundary

The comparison the README invites is with OpenClaw, and the difference is not feature count. It is where the trust boundary sits. OpenClaw is described as enforcing security at the application level through allowlists and pairing codes, with everything in one Node process and shared memory. NanoClaw moves the boundary down to the operating system: separate Linux containers, filesystem isolation, and mounts that must be granted explicitly.

That trade has a cost in the other direction. A larger project tends to accumulate integrations, community adapters and configuration surface that a small one will not. NanoClaw's answer is the skill registry plus a fork, which puts the integration work on you. Choose OpenClaw if breadth and a configuration-driven setup matter more than reading the code that has access to your accounts. Choose NanoClaw if the opposite is true and you are willing to maintain a fork.

The provider story is a second axis. NanoClaw uses Anthropic's official Claude Agent SDK natively, with Codex, OpenCode and Ollama as drop-in options selected per agent group. That makes the model choice a per-agent decision rather than a global one.

Licence, releases and what an upgrade costs you

NanoClaw is MIT licensed. In practical terms that permits modification and redistribution with the licence and copyright notice retained; it is the licence that makes the fork-first model coherent, since the project assumes you will ship modified copies. This is a description of the licence text, not legal advice, and the LICENSE file in the repository is the authority.

The release cadence visible in the repository is fast. v2.3.0 is dated 2026-08-24, v2.2.0 is dated 2026-08-13, and v2.1.54 is dated 2026-08-01. The last push to the default branch was on 2026-08-24. Three releases in under four weeks, with patch releases in between, means a fork can drift quickly.

That drift is the real upgrade cost. Because customization happens in code and channels arrive by copying modules into your tree, every release is a potential conflict between your edits and upstream changes. The repository does include tooling aimed at this: a mailbox-model:check script that compares a generated model file against its source, and a stdin-json:check script, both of which fail when the copies fall out of sync. The migration script exists for the v1 to v2 jump, but the README does not describe an equivalent automated path for keeping a customized v2 fork current.

Where NanoClaw is the wrong choice

If you need a shared assistant for an organization, the per-agent container and per-agent memory model works against you. The isolation that makes the project attractive to an individual is overhead when many people must share one identity and one memory.

If you want to install software and configure it rather than own a fork, the README's own philosophy rules this out. There is no supported path to behavior changes that does not involve editing code.

If you need a channel the channels branch does not cover, there is no generic adapter to fall back on. And if your deployment target is native Windows, the container isolation the project is built around is listed for macOS, Linux and WSL2 only.

Finally, if you need operational visibility, plan around its absence. There is no dashboard and no debugging UI in the trunk; the documented workflow is to describe the problem in chat.

Editorial conclusion

Adopt NanoClaw if you are a single technical user who wants an agent wired into your messaging apps, expects to fork the repository, and values OS-level container isolation over a plugin ecosystem. Do not adopt it if you need a hosted product with a dashboard, a multi-tenant deployment, or a project that takes pull requests for your custom behavior; the README is explicit that customization means code changes and that channels and providers live on separate branches. Before committing, verify that Docker is available on your target platform (macOS, Linux or WSL2), that your Anthropic credential can be registered with OneCLI, and that the channel you actually need exists as an /add-<channel> skill in the repository, because the trunk ships the registry and infrastructure rather than the adapters themselves.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes