NanoClaw — the harness you are supposed to fork

A rewrite of OpenClaw whose argument is that the original is too large to trust with your life. MIT, TypeScript, by nanocoai. 30,570★ / 12,841 forks / 926 open issues, repository created 2026-01-31, last pushed on the day it was read (2026-08-20). Runs Claude Code through Anthropic's official Claude Agent SDK, with OpenAI Codex, OpenCode and Ollama as drop-in alternatives configurable per agent group.

The security argument, made from inside the clone

The README states its motive plainly: "I wouldn't have been able to sleep if I had given complex software I didn't understand full access to my life." Its charge against OpenClaw is that security sits "at the application level (allowlists, pairing codes) rather than true OS-level isolation," with everything in one Node process and shared memory.

NanoClaw's answer is containers. Each agent group gets "its own CLAUDE.md, its own memory, its own container, and only the mounts you allow," and the pitch for shell access follows from that: "Bash access is safe because commands run inside the container, not on your host." Credentials are held away from the agent entirely — outbound requests route through OneCLI's Agent Vault, which injects them at request time and enforces per-agent policy and rate limits.

That is the same move NVIDIA's OpenShell makes — guardrails as external containment rather than as in-agent permission checks — arriving from the opposite direction. The spoke had recorded containment as the thing platform vendors bolted onto OpenClaw because the project would not do it. NanoClaw is the case where the containment argument is the whole reason a competing implementation exists, and it comes from an independent developer rather than from a company with a runtime to sell. agent-scope-isolation gains an instance where isolation is the product, not a feature.

Small so that a model can rewrite it

The more unusual claim is about size, and it is not the ordinary minimalism pitch. "One process, a few source files and no microservices. If you want to understand the full NanoClaw codebase, just ask Claude Code to walk you through it." Configuration is rejected outright — "Customization = code changes. No configuration sprawl. Want different behavior? Modify the code." — and the intended way to change behaviour is to describe it in chat and let Claude Code edit your fork.

So the codebase is kept small for an agent's comprehension budget, not a human's, and the ceiling being respected is a context window. Every harness in this spoke so far treats the agent as the thing being built; here the agent is also the maintainer, and legibility-to-a-model becomes a design constraint on the source tree.

Distribution follows: trunk ships only the registry and infrastructure. Channel adapters live on a channels branch and alternative providers on a providers branch, installed into your own fork by running /add-telegram, /add-ollama-provider and so on. The contribution rule is "Don't add features. Add skills." That is the skills thesis — progressive disclosure, load only what this job needs — turned on the harness's own repository.

The fork ratio says the model is real

Read on 2026-08-20, forks against stars:

Stars measure attention and forks measure intent to modify, so the ratio is a rough read on how many admirers become operators. NanoClaw's is double OpenClaw's and nearly triple MimiClaw's, on a repository seven months old. A project that instructs every user to fork it and edit the fork should produce exactly that signature, and it does. Worth holding loosely: forks are also created by drive-by contributors and by anyone clicking through a tutorial, and no source here separates a fork that runs from one that never did.

What is claimed and not verified

The numbers about OpenClaw are NanoClaw's. "Nearly half a million lines of code, 53 config files, and 70+ dependencies" is a competitor's characterization of a rival, recorded here as a claim and not as a measurement. Nobody in this corpus has counted OpenClaw's lines. It is the same epistemic shape as the vendor benchmarks the hub keeps flagging, and it should be read that way even though the direction of the argument is sympathetic.

Also unmeasured: whether container isolation delivers what it promises against a prompt-injected agent. The README asserts that bash is safe inside the container; no evaluation, no threat model against a hostile page or a malicious skill, and ClawHub's 341 malicious skills are the standing demonstration that skill supply is where this class of system actually gets hurt. Docker on macOS runs inside a VM and on Linux does not, which is a materially different isolation boundary, and the README does not distinguish them.

One privacy detail worth keeping because it is unusually specific: no user accounts, anonymous setup diagnostics only, NANOCLAW_NO_DIAGNOSTICS=1 to disable, with the single exception that fetching the prebuilt hardened image requires a free account and therefore reveals an email address. Building the image locally contacts nothing and is the default.

Architecture, briefly

messaging apps → host process (router) → inbound.db → container (Bun, Claude Agent SDK)
→ outbound.db → host process (delivery) → messaging apps

One Node host orchestrates per-session containers. Two SQLite files per session with exactly one writer each, which is how the design avoids IPC, stdin piping and cross-mount contention altogether. Channels supported once installed: WhatsApp, Telegram, Discord, Slack, Microsoft Teams, iMessage, Matrix, Google Chat, Webex, Linear, GitHub, WeChat and email via Resend. Requires Node 22+, pnpm 10+ and Docker; Claude Code is a hard dependency for /customize, /debug and every /add-<channel> skill.

Related

openclaw · mimiclaw · nemoclaw · agent-scope-isolation · agent-guardrails · agentic-coding-harness · agent-skills · synthesis