#I am going to be shipping an isolation

1 messages ยท Page 1 of 1 (latest)

lone dune
#

i would like to take a look. thanks

odd laurel
#

Nice. Is this another layer on top of the sandboxing feature?

amber imp
#

@odd laurel its actually a layer below

The main difference is that OpenClaw uses Docker containers to isolate tool execution, while the app I have uses OS-level kernel sandboxing (Landlock on Linux, Seatbelt on macOS). With OpenClaw you need to set up Docker, configure the gateway, pull images, and set up workspace mounts before you can run anything. With the new app you just type โจnono --allow ~/.openclaw openclaw gatewayโฉ and you're done - single binary, no dependencies.

The other difference is the security model. OpenClaw has an explicit "elevated execution" escape hatch that lets tools bypass the sandbox when needed, and their docs acknowledge it's "not a perfect security boundary." nono has no escape hatch by design - once the sandbox is applied at the kernel level, there's no API to expand permissions, even if the agent gets prompt-injected into trying.

Basically the way I have built it trades flexibility for stronger guarantees and zero setup friction.

Having said that, you could run both together, with nono being an immovable foundation to protect critical files and keys

Its built in rust, so I can get close to lower level system calls

#

and something i meant to mention, it works with most agents, so you could also use it for claude code, opencode etc

odd laurel
#

This is awesome

#

The in-built sandboxing feature is overcomplicated imo. I've been in platform engineering for years and it's taken me a minute to wrap my head around the security model

#

Makes me doubt that it's providing any real security for most users

#

Definitely post here when it's ready. Would love to try