Live data from Hacker News

Run NanoClaw in Docker Sandboxes

nanoclaw.dev

41–50 of 64 posts

Re: Run NanoClaw in Docker Sandboxes

#41

What 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?

It's simply just either a LLM-cron job OR a telegram/email/etc chat connector to a sandboxed LLM. For former can be solved with regular cron jobs and the later can be done via manual code or Gemini Gems (if you use google).

Re: Run NanoClaw in Docker Sandboxes

#42
The next step to this is using a better tool to access containers (BuildKit), like Dagger, where you can track every step as a new container layer, time travel, share via registries...

This has been my setup since early this year, not even that much code: https://github.com/hofstadter-io/hof/tree/_next/lib/agent/se...

The bigger effort is making it play nice with vscode so you can browse and edit the files and diffs.

Re: Run NanoClaw in Docker Sandboxes

#44
post #11

They 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…

I get the appeal but I disagree The strength of open source software is collaboration. That many people have tried it, read it, submitted fixes and had those fixes reviewed and accepted. We've all seen LLMs spit out garbage bugs on the first few tries. I've written garbage bugs on my first try too. We all benefit from the review process. I would rather have a battle tested base to start customizing from than having t…

> We've all seen LLMs spit out garbage bugs on the first few tries.

I’m assuming here an extrapolation of capabilities where Claude is competitive to the median OSS contributor for the off-the-shelf libraries you’d be comparing with.

As with most of the Clawd ecosystem, for now it probably is best considered an art project / prototype (or a security dumpster fire for the non-technical users adopting it).

> The strength of open source software is collaboration. That many people have tried it, read it, submitted fixes and had those fixes reviewed and accepted

I do think that there is room for much more granular micro-libraries that can be composed, rather than having to pull in a monolithic dependency for your need. Agents can probably vet a 1k microlibrary BoM in a way a human could never have the patience to.

(This is more the NPM way, leftpad etc, which is again a security issue in the current paradigm, but potentially very different ROI in the agent ecosystem.)

Re: Run NanoClaw in Docker Sandboxes

#45
post #11

They 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.

Except it's not 'once' though.

In order for it to be 'once': all hardware must have been, currently be, and always will be: interchangeable. As well as all OS's. That's simply not feasible.

Re: Run NanoClaw in Docker Sandboxes

#47
post #5

You 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…

That's a great question, and it reminds me of something I read today:

https://entropytown.com/articles/2026-03-12-openclaw-sandbox...

The core issue, to me, is that permissions are inherently binary — can it send an email or not — while LLMs are inherently probabilistic. Those two things are fundamentally in tension.

Re: Run NanoClaw in Docker Sandboxes

#48
post #6

All the sandboxing stuff is neat but the weakest link in these claw setups is not root access on the machine but root access to your life (Gmail, calendar, etc)

why give it root access to your life? i don't use these tools but it seems like you should never give anything that access. if a claw needs email, set up a google account just for it and forward relevant stuff to it. share your calendar with it. whatever, just don't let it "be" you. access control, provisioning, and delegation have been solved for a very long time now.

How do you control access or delegate with typical web apps like Gmail, Calendar, Expedia?

Re: Run NanoClaw in Docker Sandboxes

#49
post #5

You 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…

[dead]

Re: Run NanoClaw in Docker Sandboxes

#50

Earlier quoted context omitted.

> 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.

Except it's not 'once' though. In order for it to be 'once': all hardware must have been, currently be, and always will be: interchangeable. As well as all OS's. That's simply not feasible.

I don't see, how is it relevant in this case. We are talking about writing an integration with an HTTP API (probably) in a high level language (TS/JS, Python, etc). We have already abstracted hardware away.
Post reply on HN