An AI assistant that runs agents securely in their own containers. Lightweight, built to be easily understood and completely customized for your needs.
nanoclaw.dev •
docs •
中文 •
日本語 •
한국어 •
Agents in Slack: one app per agent 
Setup provisions each agent its own Slack app: manifest, avatar, and workspace install, no tokens to paste. Spawn teammates from chat: every one gets its own bot identity, container, and memory, with shared rooms and canvases.
Why I Built NanoClaw
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. Agents run in their own Linux containers with filesystem isolation, not merely behind permission checks.
Quick Start
git clone https://github.com/nanocoai/nanoclaw.git nanoclaw-v2
cd nanoclaw-v2
bash nanoclaw.shnanoclaw.sh walks you from a fresh machine to a named agent you can message. It installs Node, pnpm, and Docker if missing, installs a credential gateway and registers your Anthropic credential with it, builds the agent container, and pairs your first channel (Slack, Telegram, Discord, WhatsApp, iMessage, or a local CLI). If a step fails, Claude Code is invoked automatically to diagnose and resume from where it broke.
Migrating from NanoClaw v1?
Run from a fresh v2 checkout next to your v1 install:
git clone https://github.com/nanocoai/nanoclaw.git nanoclaw-v2
cd nanoclaw-v2
bash migrate-v2.shmigrate-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, shared-memory migration, 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, the credential gateway, 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 the Baileys keystore for WhatsApp — LID mapping is now resolved per-message by the Baileys v7 adapter, not migrated), 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.
Philosophy
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.
What It Supports
- Multi-channel messaging — WhatsApp, Telegram, Discord, Slack, Microsoft Teams, iMessage, Matrix, Google Chat, Webex, Linear, GitHub, WeChat, and email via Resend. Installed on demand with
/add-<channel>skills. Run one or many at the same time. - Flexible isolation — connect each channel to its own agent for full privacy, share one agent across many channels for unified memory with separate conversations, or fold multiple channels into a single shared session so one conversation spans many surfaces. Pick per channel via
/manage-channels. See docs/isolation-model.md. - Per-agent workspace — each agent group has its own
CLAUDE.md, its own memory, its own container, and only the mounts you allow. Nothing crosses the boundary unless you wire it to. - Scheduled tasks: recurring jobs executed by the agent, with optional script gates that avoid waking it when there is no work
- Web access — search and fetch content from the web
- Container isolation — agents are sandboxed in Docker containers (macOS/Linux/WSL2)
- Credential security — agents never hold raw API keys. Outbound requests route through a credential gateway that injects credentials at request time and enforces per-agent policies and rate limits. Which gateway is yours to pick: setup installs one (currently OneCLI's Agent Vault) behind a provider seam.
- Agent templates: stamp a ready-to-run agent (instructions + MCP tools + skills, no secrets) from a reusable bundle via
ncl groups create --template <ref>. Templates load from the localtemplates/folder; populate it by hand or by copying from the public library. See docs/templates.md.
Accounts and what leaves your machine
NanoClaw has no user accounts. The only thing it reports is anonymous setup diagnostics, and
NANOCLAW_NO_DIAGNOSTICS=1 turns those off. Your agents, messages, files and keys never leave
your machine.
One opt-in exception: you can fetch a prebuilt agent image instead of building it locally. Fetching ours needs a free account, so we see your email address and when you ask for an image — nothing about your agents, and nothing after the image lands. Building locally needs no account and contacts nothing, and is the default. The same account unlocks the perks below.
Perks
The free account also opens the community portal at portal.nanoclaw.dev, a dashboard where you switch on what the account offers. Today that is Echo's hardened agent image and a managed Slack app for your agent, created and installed for you with no tokens to paste. Everything else in NanoClaw works without it.
Setup opens the portal once. You sign in in the browser, approve the terminal you are running setup from, and enable the perk; the wizard notices and continues on its own. Enabling Echo is where you agree to Echo's terms, including whether you want product and security email. Close the page without enabling anything and setup carries on without the perk, then offers it once more later.
What stays on your machine: the sign-in record and install token in ~/.config/nanoclaw/account.json,
one device key per machine in ~/.config/nanoclaw/device-key.json, and this checkout's journal in
data/community-portal.json (which perks are on, setup progress, the credentials a perk handed
you), all mode 0600. The install token never passes through the browser: the browser sees only
the one-time sign-in code, and the token reaches this machine from the account service directly.
The host keeps one outbound connection to the portal so a perk you change in the browser reaches
the running agent; it sends nothing about your agents, messages or files.
Revisit a step with pnpm exec tsx setup/portal.ts --stage echo or --stage slack. To sign a
machine out, forget it under Devices in the portal: its token stops working and the host
disconnects. Files, recovery commands and troubleshooting: docs/community-portal.md.
Usage
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
Customizing
NanoClaw doesn't use configuration files. To make changes, just tell Claude Code what you want:
- "Change the trigger word to @Bob"
- "Remember in the future to make responses shorter and more direct"
- "Add a custom greeting when I say good morning"
- "Store conversation summaries weekly"
Or run /customize for guided changes.
The codebase is small enough that Claude can safely modify it.
Contributing
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.
RFS (Request for Skills)
No channel or provider skills are currently requested — propose one via an issue.
Requirements
- macOS or Linux (Windows via WSL2)
- Node.js 22+ and pnpm 10+ (the installer will install both if missing)
- Docker Desktop (macOS/Windows) or Docker Engine (Linux)
- Claude Code for
/customize,/debug, error recovery during setup, and all/add-<channel>skills
Architecture
messaging 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 the agent, 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 files:
src/index.ts— entry point: DB init, channel adapters, delivery polls, sweepsrc/router.ts— inbound routing: messaging group → agent group → session →inbound.dbsrc/delivery.ts— pollsoutbound.db, delivers via adapter, handles system actionssrc/host-sweep.ts— 60s sweep: stale detection, due-message wake, recurrencesrc/session-manager.ts— resolves sessions, opensinbound.db/outbound.dbsrc/container-runner.ts— spawns per-agent-group containers, leases the session's gateway contributionsrc/db/— central DB (users, roles, agent groups, messaging groups, wiring, migrations)src/channels/— channel adapter infra (adapters installed via/add-<channel>skills)src/providers/— host-side provider config (claudebaked in; others via skills)container/agent-runner/— Bun agent-runner: poll loop, MCP tools, provider abstractiongroups/<folder>/— per-agent-group filesystem (CLAUDE.md, skills, container config)
FAQ
Why Docker?
Docker provides cross-platform support (macOS, Linux and Windows via WSL2) and a mature ecosystem.
Can I run this on Linux or Windows?
Yes. Docker is the default runtime and works on macOS, Linux, and Windows (via WSL2). Just run bash nanoclaw.sh.
Is this secure?
Agents run in containers, not behind application-level permission checks. They can only access explicitly mounted directories. Credentials never enter the container — outbound API requests route through the installed credential gateway, which injects authentication at the proxy level and supports rate limits and access policies. You should still review what you're running, but the codebase is small enough that you actually can. See the security documentation for the full security model.
Why no configuration files?
We don't want configuration sprawl. Every user should customize NanoClaw so that the code does exactly what they want, rather than configuring a generic system. If you prefer having config files, you can tell Claude to add them.
Can I use third-party or open-source models?
Yes. The supported path is /add-opencode (OpenRouter, OpenAI, Google, DeepSeek, and more via OpenCode config) or /add-ollama-provider (local open-weight models via Ollama). Both are configurable per agent group, so different agents can run on different backends in the same install.
For one-off experiments, any Claude API-compatible endpoint also works via .env:
ANTHROPIC_BASE_URL=https://your-api-endpoint.com
ANTHROPIC_AUTH_TOKEN=your-token-hereHow do I debug issues?
Ask Claude Code. "Why isn't the scheduler running?" "What's in the recent logs?" "Why did this message not get a response?" That's the AI-native approach that underlies NanoClaw.
Why isn't the setup working for me?
If a step fails, nanoclaw.sh hands off to Claude Code to diagnose and resume. If that doesn't resolve it, run claude, then /debug. If Claude identifies an issue likely to affect other users, open a PR against the relevant setup step or skill.
How do I uninstall NanoClaw?
bash nanoclaw.sh --uninstallEvery install is tagged with a per-checkout id, so the uninstaller removes only what belongs to that copy: the background service, containers and image, app data and logs, your agents' files, and this copy's gateway agents. Shared things — the gateway service and your credentials, other NanoClaw copies on the machine — are left alone. It shows exactly what it found and asks for confirmation per group; nothing is deleted until you say yes. Use --dry-run to preview without changing anything, or --yes to skip the prompts. Your .env is backed up before removal. To finish, delete the checkout folder itself.
What changes will be accepted into the codebase?
Only security fixes, bug fixes, and clear improvements will be accepted to the base configuration. That's all.
Everything else (new capabilities, OS compatibility, hardware support, enhancements) should be contributed as skills: channel and provider code on the channels/providers registry branches, everything else as a self-contained skill. See docs/customizing.md and CONTRIBUTING.md.
This keeps the base system minimal and lets every user customize their installation without inheriting features they don't want.
Community
Questions? Ideas? Join the Discord.
Changelog
See CHANGELOG.md for breaking changes, or the full release history on the documentation site.
License
MIT
