nono: the agent sandbox from the people who signed your package registry

Sigstore's team, applied to agents

The provenance line is doing real work, nono is built by the team that brought you Sigstore, the standard for secure software attestation used by PyPI, npm, brew and Maven Central, with Luke Hinds named as author in the workspace manifest. That lineage shows in the product shape, the same instinct that signed supply chains now confines agents, and there is even an agent-sign action on the GitHub Marketplace extending the attestation story to agent work. The adoption claims are grounded in named testimonials, a Datadog staff security engineer citing fine grained per command policies and sophisticated credential management fitting complex real world toolchains, and an Okta principal engineer describing credentials locked down without sacrificing developer velocity. The README also claims the category, nono pioneered the zero latency zero setup agent sandbox, and has been copied by many.

No daemon, no container, no VM

The pitch is stated as a triple negation, no daemon, no container, no VM, and no disk space usage, getting agents running within seconds rather than after an image pull or a hypervisor boot. Out of the box it enforces a least privilege sandbox on macOS, Linux and Windows under WSL2, and the zero latency claim is the operational point, a sandbox whose startup cost is invisible at interactive agent speeds gets used, while one that adds seconds per command gets disabled. The supported agent list names Claude Code, Codex, Pi, Copilot, Hermes, OpenCode and OpenClaw among others, and profiles for all the popular agents live in the registry, secured and ready to pull, each bundling the right filesystem scope, network allowlist, hooks and skills.

search, run, and the current directory contract

The first run is two commands, find an agent in the registry, then run it:

nono run --profile nolabs-ai/opencode -- opencode

after a search step that locates the profile. The contract that follows is the product's core promise in one sentence, the agent now runs with read and write access to the current directory and nothing else, SSH keys, cloud credentials, and the rest of the disk are invisible to it. Installation is equally short, a curl piped script, brew install nono, or a Nix flake offering a from source build and a prebuilt binary output, with the pin example resolving the latest release tag through the GitHub API for reproducible runs, and packages for Debian, Fedora, Arch, RHEL, openSUSE and WSL2 documented separately.

Profiles as composable, reviewable JSON

Customization starts from inheritance, nono profile init opencode --extends nolabs-ai/opencode exports an editable profile that inherits from the base, and nono run --profile opencode runs the local version, the same command with your file instead of the registry's. Profiles are composable JSON, so the exact filesystem, network, credentials and tool rules are reviewable before sharing with a team or publishing to the community, the property that makes sandbox policy auditable rather than folklore. Agent developers are invited to publish their own agent packages through the documented publishing flow, with the registry as the distribution point, and the recent organization migration note, always-further to nolabs-ai with remove and pull commands to move installed packs, shows the registry operating at a scale where namespace hygiene matters.

Sandboxing the tools, not just the agent

The argument that separates nono from blanket sandboxes is about where the risk actually lives, agents delegate real work to tools, git, gh, curl, kubectl, package managers, build scripts, MCP clients and servers, whatever is on PATH, and those tools are where secrets, network access and side effects show up. Most sandboxes give the agent one policy where a secret is universally available to the entire agent and every tool, and nono instead puts delegated tools in their own isolated command sandboxes outside the agent's control, a broker launching each controlled tool under its own command policy with its own filesystem, network and credential rules. The command sandbox inherits nothing from the session, not the broad allow grants, not CWD access, not raw credential paths, not network access, unless its own policy says so.

Credential proxies and L7 filtering

The documented policy examples are concrete enough to evaluate, the agent may call git, but git only gets the repository, trusted Git config files and the Git object store, the agent may call gh, but gh only receives a GitHub token through nono's credential proxy, and that token may only be used against selected GitHub API methods and paths through L7 filtering, application layer rules rather than bare host allowlists. Chaining is modeled too, git may call ssh under a chained policy while direct ssh from the agent stays denied, the distinction real workflows need. The credential machinery in the profile JSON shows the shape, a proxy type entry with the upstream API, a keyring credential key, an environment variable name and an injected Authorization header, so tokens flow through nono rather than sitting in the agent's environment. The framing line closes it, the policy lives in the profile, not in the prompt, and the agent cannot widen a tool's sandbox, mint keys, or bypass endpoint policy from inside the session.

Landlock, zeroize, and a proxy crate

The Cargo workspace names its parts, nono as the core library, nono-cli, nono-proxy for the credential and network broker, test support, and C FFI bindings generated with cbindgen, built on edition 2024 with Rust 1.95. The dependency list reads as an architecture document, landlock for Linux filesystem sandboxing, the kernel LSM mechanism rather than a userspace imitation, nix for the Unix primitives, zeroize with alloc and serde features for scrubbing credential material from memory, tokio and hyper powering the proxy, and walkdir, ignore and globset for the filesystem scoping rules. Quality gates are strict, clippy denies unwrap across the workspace, and the release profile runs thin LTO with a single codegen unit and panic set to abort. A Makefile orchestrates build, workspace tests, and ARM64 cross compilation through cross, with a SPIFFE test target beside the usual suites.

NEPs, governance, and a September cadence

The repository carries the apparatus of a governed open source project, an neps directory of enhancement proposals, GOVERNANCE.md, MAINTAINERS.md and a CONTRIBUTORS file, plus the coding agent files, AGENTS.md and CLAUDE.md, that a tool built for agents unsurprisingly hosts for its own development. The README frames the current phase honestly, in the lead up to a 1.0 release APIs are stabilizing, changes may still occur but will be kept to a minimum. Release cadence is fast, v0.76.0 on 2026-09-09, v0.77.0 two days later, v0.78.0 on 2026-09-16, with the repository pushed 2026-09-29, the day before this writing, under Apache-2.0 with tool sandbox examples and docker packaging in the tree.

Editorial conclusion

Adopt nono when agents need to run with real tools against real repositories while credentials and the rest of the machine stay invisible, since its per tool command policies and credential proxying solve exactly the gap between a blanket sandbox and a trustworthy one, a gap Datadog and Okta engineers describe in the project's own testimonials. It presumes comfort with policy-as-config, profiles are JSON with filesystem, network and credential rules to review. Before adopting, complete the namespace migration from always-further to nolabs-ai if you predate it, treat the API as stabilizing but not frozen ahead of 1.0, and start from a registry profile for your agent, extending rather than writing policy from scratch.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes