gavrielc/nanoclaw: My personal Claude assistant that runs in Apple containers. Lightweight, secure, and built to be understood and customized for your own needs.

My personal cloud assistant that runs securely in Apple containers. Lightweight and built to understand and customize as per your own needs.

OpenClaw is an impressive project with a great vision. But I don’t sleep well letting software I don’t understand access my life. OpenClaw has 52+ modules, 8 configuration management files, 45+ dependencies and abstractions for 15 channel providers. Security is application-level (permission list, pairing code) rather than OS isolation. Everything runs in a single node process with shared memory.

NanoClaw gives you the same core functionality in a codebase you can understand in 8 minutes. a process. A handful of files. Agents run in real Linux containers with file system isolation, not behind permission checks.

git clone https://github.com/gavrielc/nanoclaw.git
cd nanoclaw
claude

then run /setup. Cloud Code handles everything: dependencies, authentication, container setup, service configuration.

Small enough to understand. One process, some source files. No microservices, no message queues, no abstraction layers. Ask Cloud Code to guide you through it.

Protected by isolation. Agents run in Linux containers (Apple containers). They can only see what is clearly imposed. Bash access is secure because the commands run inside the container, not on your Mac.

Designed for one user. This is not a structure. This is working software that meets my exact requirements. You fork it and you have cloud code that matches it to your exact needs.

Customization = code changes. No configuration spillover. Want different behavior? Modify the code. The codebase is so small that it’s safe.

AI-native. No installation wizard; Cloud code guides setup. No monitoring dashboard; Ask Claude what’s going on. No debugging tools; Describe the problem, the cloud fixes it.

Skills over features. Contributors must not add features (such as support for Telegram) to the codebase. Instead, they contribute skills like /add-telegram Which replaces your fork. In the end you get clean code that does what you need.

Best harness, best model. It runs on the Cloud Agent SDK, which means you’re running cloud code directly. Harness matters. A bad harness fools even smart models, a good harness gives them superpowers. Cloud Code is (IMO) the best harness available.

No ToS gray areas. Because it uses the Cloud Agent SDK natively without any hacks or workarounds, it is perfectly legitimate (I think) to use your subscription with your auth token. There is no risk of being shut down due to violation of terms of service (I’m not a lawyer).

• whatsapp i/o – Send messages to the cloud from your phone
• isolated group reference – each group has its own CLAUDE.md memory, isolated file system, and runs in its own container sandbox by mounting only that file system
• main channel – Your private channel (self-chat) for administrator control; Every other group is completely isolated
• scheduled tasks – Recurring jobs that run the cloud and can send messages back to you
• Web Access – Search and get content
• container isolation – Agents sandboxed in Apple containers
• optional integration – Add Gmail (/add-gmail) and many more through skills

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 the main channel (your self-chat), 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

There are no configuration files to learn. Just tell Cloud Code what you want:

• “Change trigger word to @Bob”
• “Remember to make responses shorter and more direct in the future”
• “Add a custom greeting when I say good morning”
• “Store Conversation Summary Weekly”

or run /customize For directed changes.

The codebase is small enough that the cloud can safely modify it.

Don’t add features. Add skills.

If you want to add Telegram support, don’t create a PR that adds Telegram with WhatsApp. Instead, contribute a skills file (.claude/skills/add-telegram/SKILL.md) which teaches CloudCode how to convert a NanoClaw installation to use Telegram.

users then run /add-telegram Get more clean code on their fork that does what they need, not a bloated system trying to support every use case.

Skills we’d love to see:

communication channels

• /add-telegram – Add Telegram as a channel. The user should be given the option to change WhatsApp or add it as an additional channel. It should also be possible to add it as a control channel (where it can trigger actions) or just a channel that can be used to trigger actions elsewhere.
• /add-slack – Add Slack
• /add-discord – add discord

container runtime

• /convert-to-docker – Replace Apple containers with Docker (unlocks Linux)

platform support

• /setup-windows – Windows via WSL2 + Docker

session management

• /add-clear – Add a /clear Command that summarizes a conversation (summarizes the context while preserving important information in the same session). Need to know how to trigger compaction programmatically through the Cloud Agent SDK.

WhatsApp (baileys) --> SQLite --> Polling loop --> Container (Claude Agent SDK) --> Response

Single Node.js process. Agents execute in separate Linux containers with mounted directories. IPC via file system. No daemons, no queues, no complexity.

Main files:

• src/index.ts – Main Apps: WhatsApp Connection, Routing, IPC
• src/container-runner.ts – Agent spawns containers
• src/task-scheduler.ts – runs scheduled tasks
• src/db.ts – SQLite operations
• groups/*/CLAUDE.md – per-group memory

Why WhatsApp and not Telegram/Signal/etc?

Because I use WhatsApp. Fork it and run a skill to replace it. This is the whole matter.

Why Apple Containers instead of Docker?

Light, fast, and built into macOS. Requires MacOS Tahoe and runs great on Mac Mini. If you want Docker, contribute the skills to convert to Docker.

Can I run it on Linux?

Yes. Run cloud code and say “Run this on Linux.” ~30 minutes of back and forth and it should work. When you’re done, ask Cloud to create a skill explaining how to make it work on Linux, then contribute the skill to the project.

is it safe?

Agents run in containers, not behind application-level permission checks. They can only access explicitly mounted directories. You should still review what you’re running, but the codebase is small enough that you really can. See docs/SECURITY.md for the complete security model.

Why no configuration file?

We don’t want sprawl in the configuration. Each user must customize it so that the code matches exactly what they want, rather than configuring a generic system. If you like config files, ask the cloud to add them.

How do I debug issues?

Ask Cloud Code. “Why is the scheduler not running?” “What’s in the recent log?” “Why is this message not replied to?” That’s the AI-native approach.

Why isn’t setup working for me?

I don’t know. run claudethen run /debug. If Cloud finds an issue that is possibly affecting other users, open a PR to modify the setup SKILL.md.

What changes to the codebase will be accepted?

Security fixes, bug fixes, and obvious improvements to the base configuration. That’s it.

Everything else (new capabilities, OS compatibility, hardware support, enhancements) should be contributed as skills.

This keeps the base system minimal and lets each user customize their installation without getting features they don’t want.

MIT