#I am going to be shipping an isolation
1 messages ยท Page 1 of 1 (latest)
Nice. Is this another layer on top of the sandboxing feature?
@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
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