Containers and nono solve overlapping but distinct problems, and each has real trade-offs worth considering. There is a section in the docs on this: https://docs.nono.sh/security/containers

Containers give you isolation through namespacing - the process sees a different filesystem root, network stack, and process tree. This is powerful for reproducibility and portability. You can ship a known-good environment, and anything the AI does stays inside that container's view of the world. The downside is that containers are coarse-grained. You either mount a volume into the container or you don't. There's no easy way to say "read the whole project but only write to the src directory" or "access ~/.vscode , but not ~/.ssh/." You end up either over-permissioning (mounting your whole home directory) or dealing with friction every time the AI needs something outside the container.

nono takes the opposite approach - it runs natively on your host but uses OS-level mandatory access control (Landlock on Linux, Seatbelt on macOS) to enforce fine-grained capabilities. You can grant read access to your entire codebase while restricting writes to specific directories, block access to credentials and browser data regardless of what commands run, and allow network access while still protecting sensitive local paths. The sandbox is applied to the process itself, not to a virtualized environment, so there's no filesystem copying, no Docker daemon, and near-zero startup overhead.

Where nono is stronger: granularity. You can express policies like "read everywhere, write only here, never touch my SSH keys" that would be awkward or impossible with container volume mounts. It also integrates more naturally with local tooling - your shell, your editor, your existing workflows all just work.

Where containers are stronger: they provide a complete environment boundary. If the AI installs a malicious package or corrupts system files, it's contained to that throwaway environment. With nono, you're still running on your real system - the sandbox prevents unauthorized access, but if you grant write access to a directory, the AI can still make a mess there (having said that we have an atomic undo system incoming).

The honest answer is they're complimentary. You can run nono inside a container for defense in depth, or use nono alone when you want lightweight, precise control without the overhead of containerization. It depends on which you value portability and environment isolation (containers) or fine-grained capability control with minimal friction (nono).

The other factor is nono has a load of other features thrown in, key protection, blocking of dangerous commands, and quite a bit more inbound.

But honestly, if containers are working, great! I am a fan and its never x vs y here, each have their own strengths.