AI coding agents like Claude Code, OpenCode, and others are incredibly powerful — they can write code, refactor entire codebases, and automate tedious tasks. But there's a catch: they run with your permissions. That means they can read your SSH keys, access your AWS credentials, and potentially exfiltrate data to remote servers. We have seen this play out the past few days with the attacks against OpenClaw servers.
Current solutions often rely on the agent to police itself. But bugs happen. Security vulnerabilities are common. What if there was a way to make unauthorized operations structurally impossible?
Enter nono.
What is nono?
nono is a capability-based security shell that leverages kernel-level primitives to sandbox AI agents and untrusted processes. It uses Landlock on Linux and Seatbelt on macOS to create an environment where once restrictions are applied, there's no API to escape them — not even for nono itself.
The name says it all: "no" to unauthorized filesystem access, "no" to secret exfiltration, "no" to destructive commands.
Why Not Just Use Docker?
Great question. Containers are fantastic for many use cases, but they come with overhead:
- Heavyweight: Containers require images, layers, and a runtime
- Complexity: Managing volumes, networking, and permissions adds friction
- Overkill: Sometimes you just want to run a single command safely
nono is lightweight by design. It applies kernel-enforced restrictions directly to a process without spinning up containers, VMs, or additional infrastructure. You get security without the weight.
Quick Start
Install via Homebrew (macOS):
brew tap lukehinds/nono
brew install nono
Or build from source:
git clone https://github.com/lukehinds/nono.git
cd nono
cargo build --release
Run your first sandboxed command:
# Give Claude Code read/write access only to the current directory
nono run --allow . -- claude
# Separate read and write permissions
nono run --allow ./project-dir --write ./output claude
# Block network access entirely
nono run --allow . --net-block -- my-agent
# Preview what would happen (dry run)
nono run --allow . --dry-run -- my-command
Key Features
No Escape Hatch
Once nono applies the sandbox, there is no mechanism to bypass it. The kernel denies unauthorized operations — this isn't policy-based filtering that can be circumvented; it's structural enforcement.
Agent Agnostic
nono works with any CLI tool or AI agent: Claude Code, GPT wrappers, custom scripts, build tools — if it runs in a terminal, nono can sandbox it.
Defense in Depth
nono provides multiple layers of protection:
| Layer | Protection | Can Be Overridden? |
|---|---|---|
| Command blocklist | Blocks dangerous binaries (rm, dd, chmod, sudo) | Yes, with --allow-command
|
| Kernel (delete) | Blocks unlink/rmdir syscalls | No |
| Kernel (truncate) | Prevents zeroing out files | No |
| Filesystem sandbox | Restricts path access | Only via explicit --allow
|
| Network sandbox | Blocks network access | Only by removing --net-block
|
Sensitive Paths Protected by Default
SSH keys, AWS credentials, shell configs, and other sensitive paths are blocked by default. Your secrets stay secret.
Process Inheritance
When a sandboxed process spawns children, those children inherit all restrictions. There's no privilege escalation through subprocess tricks.
How It Works
┌─────────────────────────────────────────────────┐
│ Terminal │
│ │
│ $ nono run --allow ./project -- claude │
│ │
│ ┌───────────────────────────────────────────┐ │
│ │ nono (applies sandbox, then exec) │ │
│ │ │ │
│ │ ┌─────────────────────────────────────┐ │ │
│ │ │ Claude Code (sandboxed) │ │ │
│ │ │ ✓ Can read/write ./project │ │ │
│ │ │ ✗ Cannot access ~/.ssh, ~/.aws │ │ │
│ │ │ ✗ Cannot delete files │ │ │
│ │ └─────────────────────────────────────┘ │ │
│ └───────────────────────────────────────────┘ │
└─────────────────────────────────────────────────┘
- Command validation — Dangerous commands are blocked before execution
- Sandbox applied — OS-level restrictions are set (irreversibly)
- Kernel enforcement — Even allowed paths can't have files deleted
- Process execution — Your command runs with only granted capabilities
- Child inheritance — All subprocesses run under the same restrictions
Platform Support
| Platform | Mechanism | Kernel Requirement | Status |
|---|---|---|---|
| Linux | Landlock LSM | 5.13+ | ✅ Filesystem |
| Linux | Landlock LSM | 6.7+ | ✅ Filesystem + Network |
| macOS | Seatbelt | 10.5+ | ✅ Filesystem + Network |
| Windows | — | — | 🚧 Not yet supported |
Debugging: The why Command
Ever wonder why a path is blocked? nono can tell you:
$ nono why ~/.ssh/id_rsa
Path: /Users/you/.ssh/id_rsa
Status: BLOCKED
Reason: Sensitive path - SSH private keys are protected by default
This makes it easy to understand and debug sandbox behavior without trial and error.
Real-World Use Cases
Running AI coding agents safely:
nono run --allow ./my-project -- claude
Building code with restricted write access:
nono run --read ./src --write ./target -- cargo build
Running tests without network access:
nono run --allow . --net-block -- npm test
Processing files without risk of deletion:
nono run --read ./input --write ./output -- python process.py
Get Involved
nono is open source under the Apache 2.0 license. The project is still early (security auditing is ongoing), but it's ready for experimentation and feedback.
- GitHub: github.com/lukehinds/nono
- Documentation: docs.nono.sh
Conclusion
As AI agents become more powerful and autonomous, the security model of "trust the agent to behave" becomes increasingly untenable. nono offers a different approach: make bad behavior impossible at the kernel level.
Give it a try, break things (safely), and let us know what you think.
nono is created by Luke Hinds. Star the repo if you find it useful!
Top comments (0)