You don't need to use OpenClaw, NanoClaw or any of these new variants. You can literally use Codex, Claude Code, Gemini, OpenCode for the same thing. The only thing that it is missing from all of them is the communication channels because none of them come with native communication tools like OpenClaw.

But this is not such a big deal.

I made an open-source lightweight daemon in Go that fills that gap. All it does is to provide the means to connect to popular messaging systems like Slack, Discord, WhatsApp, Telegram, etc. and expose this all through the CLI.

The project is hosted here: https://github.com/pantalk/pantalk

My personal realisation recently has been that the unix way is the best way. We just need to go back creating daemons and lightweight composable CLIs and let agents do their thing. They are increasing being trained to operate the command-line and they are getting pretty good at it.

> But NanoClaw isn't just my personal project anymore. Thousands of people are using it. People are running production workloads on it. Businesses are building on it. There's a real community now.

as OpenClaw and now NanoClaw became "enterprise", now we need a new FemtoClaw to pick up the indie/boutique place

For my version of the AI assistant, I used a Docker container and Unix permissions:

https://github.com/skorokithakis/stavrobot

All plugins run in one Docker container, but they're isolated from each other by different *nix users, so they can't read each other's files. That's much more lightweight, and you don't have to run one container per plugin.

Crucially, plugins can't read each other's secrets or modify each other's code. I even have a plugin configuration webpage that doesn't go through an LLM, so the LLM never sees your secrets if you don't want to.

Putting these NanoClowns inside a container will not protect you from all kinds of safety hazards.

I’ve been building sandboxing for Claude code workloads. So I can let it run wild without breaking my computer. Originally I used docker, but I’m now in the process of jettisoning that, and switching to qemu.

For my use case I want ssh access and being able to use docker in docker. This allows for things like test containers and docker compose. You can get all of that working with docker. But you kind of have to fight docker the whole way.

NanoClaw might have different needs, and docker could work better for it, and I hope so for their sake. But I’m not optimistic.

I can't believe the solution is creating uncompatibile branch and forcing users to use cladue for resolving merge conflits. Why not bake in the dual compatibility?

I'm surprised that the developer experience around sandboxing on macOS is generally so bad. Seatbelt is in limbo and apple containers are just a pain to work with as some have highlighted in this thread

Can someone explain the special sauce of the claws compared to just use claude.ai etc

Sensible, this broadens our hosting options.

I installed nanoclaw last night funny to see it here on HN.

It was easy to install it, and get it running. I could @Andy message it on whatsapp but after that it fell apart fast.

I asked it to login to Facebook and check my notifications, and it started saving credentials and random things in the repo as json files. And din't work. It was hard to even figure out what was happening and why it didn't work.

Then I tried messaging it again and it didn't respond to me.

These things are extremely brittle despite the enourmous amount of github stars. I think it's just normies starring things trying to get on the train unfortunately. The promise of an AI Jarvis is unrealized still.

apple container is really buggy with networking

So they're making it use OCI images? Cool. Hopefully there will be good support for Podman.

Use containerd , Docker is cancer.