I’ve been running a small fleet of AI agents against real repositories. They review pull requests, argue about security footguns, and occasionally catch things I would have missed. That only works if I trust the box they live in. For me, that box is NanoClaw, not OpenClaw.
This post is the why. A follow-up covers how I extend it without turning the host into a junk drawer.
What I needed
I wasn’t looking for the widest messaging integration matrix. I was looking for something I could sleep on:
- Agents that can use tools and workspaces, not just chat
- A host small enough that I can actually read the security-sensitive paths
- Isolation that doesn’t depend on the model behaving
OpenClaw is impressive. It also concentrates a lot of power in one long-lived gateway process, with security that is mostly application policy: allowlists, pairing, configuration. That’s a fine model for some home-lab setups. It’s the wrong default when an agent has shell, files, and credentials in play.
The posture that sold me
NanoClaw’s bet is blunt: put the agent in a container and only mount what it should see. Bash is less scary when it runs inside that boundary. Credentials stay out of the agent environment and get injected on the way out through a vault/proxy model, instead of sitting next to the model’s tools. The host stays thin. The unit of risk is the agent group, not “everything this Node process can touch.”
I care less about marketing tables and more about failure modes. Prompt injection, a bad skill, a confused tool call: those will happen. The question is whether the blast radius is “this container and its mounts” or “the whole gateway and every secret it knows.” NanoClaw answers that at the OS layer. OpenClaw answers more of it at the app layer. I want the kernel on my side.
Security still isn’t free. You have to review mounts, keep the host patched, and treat every new channel as a trust boundary. Isolation is the floor, not the ceiling. But it’s a floor I’m willing to build on.
How I actually use it
Day to day, NanoClaw is my local multi-agent desk. Specialized agents (pragmatic shipper, backend stickler, DX-minded reviewer, efficiency hawk) work in their own groups. They review the open-source packages I publish, leave structured findings, and push me when a security claim isn’t wired up on the real path. Messages go through the normal NanoClaw delivery path. I talk to them from a local web chat instead of pretending Slack is my IDE.
Memory that should follow me across tools lands in Skein over MCP. The agents stay sandboxed. The durable thread of context lives in a system designed for that job.
What I traded away
NanoClaw isn’t the feature-richest claw. If you need every channel and every plugin yesterday, OpenClaw’s gravity is real. I traded breadth for a smaller trunk, container isolation by default, and a host I can extend with installable skills instead of forever-forking. That trade matches how I already think about agentic engineering: speed is only useful inside a scaffold you trust.
Who this is for
If your agents are toys, pick whatever is fun. If they touch real code, real files, or anything adjacent to production judgment, start with isolation you can explain to another engineer in five minutes. For me, that explanation is NanoClaw.
Next: how I extended it, covering hosthooks, webchat, agenttrace, and adminapi, and why those packages stay out of core. For the agents that review, file bugs, and ship code on those packages, see meet my NanoClaw agent team.
Running agents safely is the same problem as running teams safely: clear boundaries, small blast radius, and tools that make the work visible. If you’re building that scaffold inside your company, let’s talk.