by nanocoai
A lightweight alternative to OpenClaw that runs in containers for security. Connects to WhatsApp, Telegram, Slack, Discord, Gmail and other messaging apps,, has memory, scheduled jobs, and runs directly on Anthropic's Agents SDK
# Add to your Claude Code skills
git clone https://github.com/nanocoai/nanoclawGuides for using ai agents skills like nanoclaw.
Last scanned: 5/10/2026
{
"issues": [],
"status": "PASSED",
"scannedAt": "2026-05-10T06:32:56.657Z",
"semgrepRan": false,
"npmAuditRan": true,
"pipAuditRan": true
}OpenClaw is an impressive project, but I wouldn't have been able to sleep if I had given complex software I didn't understand full access to my life. OpenClaw has nearly half a million lines of code, 53 config files, and 70+ dependencies. Its security is at the application level (allowlists, pairing codes) rather than true OS-level isolation. Everything runs in one Node process with shared memory.
NanoClaw provides that same core functionality, but in a codebase small enough to understand: one process and a handful of files. Claude agents run in their own Linux containers with filesystem isolation, not merely behind permission checks.
git clone https://github.com/qwibitai/nanoclaw.git nanoclaw-v2
cd nanoclaw-v2
bash nanoclaw.sh
nanoclaw.sh walks you from a fresh machine to a named agent you can message. It installs Node, pnpm, and Docker if missing, registers your Anthropic credential with OneCLI, builds the agent container, and pairs your first channel (Telegram, Discord, WhatsApp, or a local CLI). If a step fails, Claude Code is invoked automatically to diagnose and resume from where it broke.
Run from a fresh v2 checkout next to your v1 install:
git clone https://github.com/qwibitai/nanoclaw.git nanoclaw-v2
cd nanoclaw-v2
bash migrate-v2.sh
migrate-v2.sh finds your v1 install (sibling directory, or NANOCLAW_V1_PATH=/path/to/nanoclaw), migrates state into the v2 checkout, then execs into Claude Code to finish the parts that need judgment (owner seeding, CLAUDE.local.md cleanup, fork-customisation replay).
Run the script directly, not from inside a Claude session — the deterministic side needs interactive prompts and real shell I/O for Node/pnpm bootstrap, Docker, OneCLI, and the container build.
What it does: merges .env, seeds the v2 DB from registered_groups, copies group folders + session data + scheduled tasks, installs the channel adapters you select, copies channel auth state (including Baileys keystore + LID mappings for WhatsApp), builds the agent container.
What it doesn't: flip the system service. Pick "switch to v2" at the prompt, or do it manually after testing — your v1 install is left untouched.
See docs/v1-to-v2-changes.md for what's different and docs/migration-dev.md for development notes.
Small enough to understand. 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.
Secure by isolation. Agents run in Linux containers and they can only see what's explicitly mounted. Bash access is safe because commands run inside the container, not on your host.
Built for the individual user. NanoClaw isn't a monolithic framework; it's software that fits each user's exact needs. Instead of becoming bloatware, NanoClaw is designed to be bespoke. You make your own fork and have Claude Code modify it to match your needs.
Customization = code changes. No configuration sprawl. Want different behavior? Modify the code. The codebase is small enough that it's safe to make changes.
AI-native, hybrid by design. The install and onboarding flow is an optimized scripted path, fast and deterministic. When a step needs judgment, whether a failed install, a guided decision, or a customization, control hands off to Claude Code seamlessly. Beyond setup there's no monitoring dashboard or debugging UI either: describe the problem in chat and Claude Code handles it.
Skills over features. Trunk ships the registry and infrastructure, not specific channel adapters or alternative agent providers. Channels (Discord, Slack, Telegram, WhatsApp, …) live on a long-lived channels branch; alternative providers (OpenCode, Ollama) live on providers. You run /add-telegram, /add-opencode, etc. and the skill copies exactly the module(s) you need into your fork. No feature you didn't ask for.
Best harness, best model. NanoClaw natively uses Claude Code via Anthropic's official Claude Agent SDK, so you get the latest Claude models and Claude Code's full toolset, including the ability to modify and expand your own NanoClaw fork. Other providers are drop-in options: /add-codex for OpenAI's Codex (ChatGPT subscription or API key), /add-opencode for OpenRouter, Google, DeepSeek and more via OpenCode, and /add-ollama-provider for local open-weight models. Provider is configurable per agent group.
/add-<channel> skills. Run one or many at the same time./manage-channels. See docs/isolation-model.md.CLAUDE.md, its own memory, its own container, and only the mounts you allow. Nothing crosses the boundary unless you wire it to.Talk to your assistant with the trigger word (default: @Andy):
@Andy send an overview of the sales pipeline every weekday morning at 9am (has access to my Obsidian vault folder)
@Andy review the git history for the past week each Friday and update the README if there's drift
@Andy every Monday at 8am, compile news on AI developments from Hacker News and TechCrunch and message me a briefing
From a channel you own or administer, you can manage groups and tasks:
@Andy list all scheduled tasks across groups
@Andy pause the Monday briefing task
@Andy join the Family Chat group
NanoClaw doesn't use configuration files. To make changes, just tell Claude Code what you want:
Or run /customize for guided changes.
The codebase is small enough that Claude can safely modify it.
Don't add features. Add skills.
If you want to add a new channel or agent provider, don't add it to trunk. New channel adapters land on the channels branch; new agent providers land on providers. Users install them in their own fork with /add-<name> skills, which copy the relevant module(s) into the standard paths, wire the registration, and pin dependencies.
This keeps trunk as pure registry and infra, and every fork stays lean — users get the channels and providers they asked for and nothing else.
Skills we'd like to see:
Communication Channels
/add-signal — Add Signal as a channel/customize, /debug, error recovery during setup, and all /add-<channel> skillsmessaging apps → host process (router) → inbound.db → container (Bun, Claude Agent SDK) → outbound.db → host process (delivery) → messaging apps
A single Node host orchestrates per-session agent containers. When a message arrives, the host routes it via the entity model (user → messaging group → agent group → session), writes it to the session's inbound.db, and wakes the container. The agent-runner inside the container polls inbound.db, runs Claude, and writes responses to outbound.db. The host polls outbound.db and delivers back through the channel adapter.
Two SQLite files per session, each with exactly one writer — no cross-mount contention, no IPC, no stdin piping. Channels and alternative providers self-register at startup; trunk ships the registry and the Chat SDK bridge, while the adapters themselves are skill-installed per fork.
For the full architecture writeup see docs/architecture.md; for the three-level isolation model see docs/isolation-model.md.
Key fi
No comments yet. Be the first to share your thoughts!