It would be interesting to have nanoclaw adapted to the Pi coding agent rather than Claude Code, which would combine two minimalist approaches.
Run NanoClaw in Docker Sandboxes
31–40 of 64 posts
Re: Run NanoClaw in Docker Sandboxes
#32I like NanoClaw a lot. I found OpenClaw to be a bloated mess, NanoClaw implementation is so much tighter. It's also the first project I've used where Claude Code is the setup and configuration interface. It works really well, and it's fun to add new features on a whim.
Amen, my OpenClaw instance broke last week.
Some update broke the OpenRouter integration and I haven't been able to fix the issue. I took a quick look at the code, hoping to narrow it down and it's pretty much exactly what you would expect, there's hidden configuration files everywhere and in general it's just a lot of code for what's effectively a for loop with Whatsapp integration (in my case :)).
Not to mention that their security model doesn't match my deployment (rootless and locked down Kubernetes container) so every Openclaw update seemed to introduce some "fix" for a security issue that broke something else to solve a problem I do not have in the first place :)
I've switched to https://github.com/nullclaw/nullclaw instead. Mostly because Zig seems very interesting so if I have to debug any issues with Nullclaw at least I'll be learning something new :)
Re: Run NanoClaw in Docker Sandboxes
#33What I found interesting is nanoclaw isn’t a working product out of the box. You must use a coding agent to complete it with features you want. For example add iMessage support, etc. In other words, Claude is the compiler.
I’m old enough to remember when one checked the assembly a compiler generated because early on they produced terrible assembly. Eventually they got good enough to not needing to check.
Coding agents are not close to that yet, but it’s interesting watching history repeat itself.
This narrative of the coding agents being so much better now over the last few months seems VERY exaggerated. I’m still spending a lot of time telling Claude: No, that didn’t fix the problem. Again. Can you handle this task or do I have to give it to codex?
Re: Run NanoClaw in Docker Sandboxes
#34You must explicitly state what your threat model is when writing about security tooling, isolation, and sandboxing. This threat model is concerned with running arbitrary code generated by or fetched by an AI agent on host machines which contain secrets, sensitive files, and/or exfoliate data, apps, and systems which should not be lost. What about the threat model where an agent deletes your entire inbox? Or sends you…
> We need fine grained permissions per-task or per-tool in addition to sandboxing. For example: "this request should only ever read my gmail and never write, delete, or move emails".
Yes 100%, this is the critical layer that no one is talking about.
And I'd go even further: we need the ability to dynamically attenuate tool scope (ocap) and trace data as it flows between tools (IFC). Be able to express something like: can't send email data to people not on the original thread.
Re: Run NanoClaw in Docker Sandboxes
#35They may seem like small details, but I think a couple novel design decisions are going to prove to be widely adopted and revolutionary. The biggest one (as Karpathy notes) is having skills for how to write a (slack, discord, etc) integration, instead of shipping an implementation for each. Call it “Claude native development” if you will, but “fork and customize” instead of batteries-included platforms/frameworks is…
> having skills for how to write a (slack, discord, etc) integration, instead of shipping an implementation for each
I'm not sure what is the advantage. Each user will have to waste time and tokens for the same task, instead of doing it once and and shipping to everyone.
Re: Run NanoClaw in Docker Sandboxes
#36I hope they never drop the Apple container mode. I vastly prefer it because of the lower overhead on limited RAM.
Re: Run NanoClaw in Docker Sandboxes
#37They may seem like small details, but I think a couple novel design decisions are going to prove to be widely adopted and revolutionary. The biggest one (as Karpathy notes) is having skills for how to write a (slack, discord, etc) integration, instead of shipping an implementation for each. Call it “Claude native development” if you will, but “fork and customize” instead of batteries-included platforms/frameworks is…
> having skills for how to write a (slack, discord, etc) integration, instead of shipping an implementation for each I'm not sure what is the advantage. Each user will have to waste time and tokens for the same task, instead of doing it once and and shipping to everyone.
Agreement, excellence in one domain does not confer it to others. If you've ever worked with researchers, you know for the most part they are not engineers. This is bad advice / prediction by people with hammers imo.
OCI is a good choice of reuse, they aren't having the agent reimplement that. When there is an existing SDK, no sense in rebuilding that either. Code you don't use should be compiled away anyhow.
Re: Run NanoClaw in Docker Sandboxes
#38You must explicitly state what your threat model is when writing about security tooling, isolation, and sandboxing. This threat model is concerned with running arbitrary code generated by or fetched by an AI agent on host machines which contain secrets, sensitive files, and/or exfoliate data, apps, and systems which should not be lost. What about the threat model where an agent deletes your entire inbox? Or sends you…
> We need fine grained permissions per-task or per-tool in addition to sandboxing. For example: "this request should only ever read my gmail and never write, delete, or move emails".
We already have: IAM, WIF, Macaroons, Service Accounts
Ask you resident SecOps and DevOps teams what your company already has available
Re: Run NanoClaw in Docker Sandboxes
#39What are the most obvious use cases for Nano/Open-Claw. I can't imagine anything obvious that I'd want to use it for. Is it supposed to run your digital life for you?
Email summarization, calendar notifications, briefing documents, .. the list goes on. Think of anything knowledge-based that's moderately repetitive you don't want to do, and just ask
Re: Run NanoClaw in Docker Sandboxes
#40The main issue is not so much if it needs to run inside a container or not (and to be honest there are even better isolation models, why not firecracker vm). The main issue is what are you going to do with it. It does not really matter. IMHO, until you figure out useful ways to spend tokens to do useful tasks the runtime should be a second thought. As far as security goes, running LLM in a container in just simply no…
Docker sandboxes uses a MicroVM as an additional isolation layer - its not just containers (as also mentioned in the nanoclaw post)
This still does not help with, you can call foo, but not bar. We have plenty of existing tooling for that too.