The 499-file project puts policy around local agent processes
nono's 499-file repository contains a Rust command-line tool, core library, network proxy, language bindings, profile registry support, and tests. Its job is to start an agent with an explicit set of filesystem capabilities, then keep that policy outside the agent's control. Profiles exist for Claude Code, Codex, OpenCode, OpenClaw, and other clients. Teams can copy a registry profile, inspect its JSON, restrict it further, and share the result.
The checkout held roughly 230,026 source lines despite occupying only 43.3 MB. Much of the value sits beyond basic file blocking: supervised sessions can record audits, snapshot changes for rollback, filter destinations, broker credentials, and explain denials. Command policies can launch a delegated tool in a second sandbox with narrower access than the parent agent. A profile may let the agent call gh, for example, while giving that command one token and only selected API paths.
The default filesystem is narrow while network access is open
Our 43.3 MB checkout supports a useful default for files: the common run command can expose the working directory while leaving unrelated home-directory data invisible. That reduces damage from a recursive edit or an agent wandering into SSH and cloud configuration. The profile format distinguishes read, write, and combined access, and nono why explains a denial. Those details make the boundary inspectable outside an agent's natural-language instructions.
Network policy needs deliberate attention. The documentation states that a sandboxed process has unrestricted network access by default. Operators must add a full block, allowed domains, or a named network profile to narrow egress. The supervised proxy can also inject a real API credential after the child presents a placeholder, keeping the secret out of the child process. That is useful only when the selected client honors the proxy path and the endpoint rules describe the calls it truly needs.
What happened when we ran it
Our sandbox installed 530 packages in 50 seconds, then built commit 7772508 successfully in 363 seconds. The repository contained 13 CI workflow files and a tests directory, while our scan found no Dockerfile. That fits a local binary whose main isolation mechanisms come from the host operating system. The measurement setup used an unprivileged Debian container with 3 CPUs, 12 GB of RAM, no secrets, and the lab-rust:1 image.
Cargo test ran for 346 seconds and exited with code 101. Its aggregate result was 6,112 passed and 2 failed out of 6,114. The tail shows many test binaries succeeding, then one binary ending with 14 passed and 1 failed. Cargo identifies nono-cli --test manifest_roundtrip as the rerun target. The tail does not name the other failed test or explain either failure, so any more specific diagnosis would be guesswork. This commit did not produce a clean suite in our fresh container.
A shared kernel is the boundary, and the project says so plainly
The 6,114-test suite reflects the size of the policy surface, but it does not turn nono into a virtual machine. On Linux, nono uses Landlock and related kernel controls. macOS uses Seatbelt. Both constrain processes inside the host's kernel and user context. The security policy says a genuine escape means exceeding the authority granted by the effective policy. Access that an operator explicitly allowed is expected behavior, even if the permission later proves too broad for the workload.
That model can be a good fit for interactive coding because it starts local tools without a container daemon or guest image. It is a poor fit when the untrusted program must face a separate kernel boundary. The same security policy calls the project early, says breaking changes may arrive without notice, warns that security guarantees remain unstable, and does not recommend production deployment. Those sentences carry more weight than the README's customer endorsements when deciding where sensitive automation may run.
WSL2 has 84 percent coverage and direct mode drops five services
The 230,026 source lines cover several execution paths, and their differences affect policy. Linux requires kernel 5.13 or newer. macOS has its own capability behavior. WSL2 uses Linux Landlock with documented 84 percent feature coverage, while native Windows is unsupported. Under WSL2, capability expansion is unavailable and proxy-based network filtering is blocked by default. A cross-platform team should test the same agent profile on each operating system rather than treating one JSON file as proof of identical enforcement.
Supervised mode leaves a trusted parent outside the child sandbox to provide audit records, rollback, diagnostics, capability prompts, and proxy filtering. Direct mode replaces itself with the target command and has less attack surface, but loses all five of those services. That trade is sensible for a small CI wrapper whose policy is fixed. It is much less attractive for an interactive agent that needs credential routing or an explanation when a tool fails. Selecting a mode is part of the security design, not a speed toggle.
v0.75.0 ships quickly while its security contract is still moving
GitHub recorded the last push on September 4, 2026, one day before this review, and listed 3,965 stars plus 172 combined issues and pull requests. Open issues were still being created and updated on September 5. Release v0.75.0 arrived on September 1 with proxy fixes, profile work, tool-sandbox examples, and security-model clarification. The README also warns that APIs may change before 1.0 and tells users to migrate registry references from the retired always-further namespace to nolabs-ai.
Our 363-second build succeeded, and 6,112 passing tests show far more engineering than an experimental shell wrapper. The 2 failures still matter because policy and manifest behavior are part of the product, while the upstream production warning settles the deployment question. nono is worth testing around local Claude Code or Codex sessions where a human can inspect permissions and respond to failures. A production agent runner should wait for the project's own security stance to change and for its chosen commit to pass every relevant check.