nono

Executive Summary

nono is a local agent and tool sandbox with a Rust core. It combines operating-system access restrictions with a trusted supervisor, credential proxy, and reviewable profiles. The current project emphasizes giving individual tool invocations separate authority: a build command and a deployment command need not receive the same files, network routes, or credentials.^[1][2]

The canonical repository and registry namespace are now nolabs-ai, replacing always-further. Release v0.77.0 remains pre-1.0 and removes legacy aliases and deprecation shims in preparation for 1.0. These are material migration concerns, not just branding changes.^[1][3]

See the local agent sandboxes comparison for the category context.

---

Product Overview

Profiles describe filesystem access, network policy, credentials, and tool execution. Registry packs supply agent-specific configurations; the README explicitly asks users to migrate old always-further/* references to nolabs-ai/*.^[1]

brew install nono
nono pull nolabs-ai/claude
nono run --profile nolabs-ai/claude -- claude

Installation and registry usage are documented workflows, not commands executed as part of this review.^[6][1]

The CLI is accompanied by library bindings for Python, TypeScript, and Go. Treat each integration's documentation and release compatibility as part of adoption work.^[1]

Review and recover a session

Rollback is opt-in. A supervised parent snapshots tracked files before and after execution, then offers a diff and restoration of changed files. A documented review sequence is:^[8]

nono run --rollback --profile nolabs-ai/claude -- claude
nono rollback list --recent 5
nono rollback show SESSION_ID --diff
nono rollback restore SESSION_ID --dry-run

Replace SESSION_ID with an ID returned by the list command. The final command previews a restore; it does not change files. Snapshots respect profile exclusions and .gitignore, so an excluded artifact is not recoverable through this mechanism. Atomic rename is per file, not a transaction across every file or a rollback of remote API effects. Keep backups for data outside the tracked set. These commands were reviewed against current documentation, not run for this report.^[8]

Separate audit records from file recovery

A normal nono run records supervisor-observed events and protects that event log with integrity metadata. --audit-integrity additionally hashes tracked filesystem state; --rollback stores contents for recovery. These options solve different needs and have different storage costs.^[11]

Use nono audit list --recent 5 to locate a session, nono audit show SESSION_ID --json to inspect/export it, and nono audit verify SESSION_ID to check recorded integrity. For signed sessions, --public-key-file pins verification to an independently selected key. An internally consistent local ledger alone cannot prove an attacker controlling the host has not replaced its entire history.^[11][12]

Verify instruction provenance

Start local signing with nono trust keygen. A signed user-level policy is the trust anchor; a project-only policy produces a warning rather than establishing authoritative trust. For a new setup, nono trust init --user and nono trust sign-policy --user establish that layer. Keep an existing organizational policy intact. Then nono trust init --include "SKILLS.md" --include "CLAUDE.md", nono trust sign-policy, nono trust sign --all, and nono trust verify --all define and verify project files. Trust scanning does not honor .gitignore, although documented heavy-directory exclusions still apply.^[9]

A valid signature establishes integrity and an accepted signer, not that a skill's instructions are harmless. Keyless signing currently requires CI-provided OIDC; local development uses keyed signing, with a file-backed option for headless systems. Keep signing authority outside the agent's writable scope.^[9]

---

Technical Architecture

On Linux, nono uses Landlock; on macOS it uses Seatbelt. These restrict an individual process and its descendants without creating a separate guest kernel. The host kernel, supervisor, broker, and policy configuration remain trusted.^[12]

Irreversible child policy does not mean an irreversible session. A sandboxed child cannot remove its own kernel restrictions, but the supervisor stays outside that boundary. It can launch a new child with different grants and, on supported Linux systems, delegate an approved file descriptor. This distinction replaces the earlier profile's absolute claim that even nono cannot grant more access.^[12]

Tool policies are additional boundaries, not an automatic classification of every executable. Command resolution, direct-exec bypass settings, caller-to-command rules, and writable executable exceptions affect whether the intended control applies. Review the effective policy rather than assuming a command name alone is protected.^[2]

---

Strengths

• Different tools can receive different authority. A narrow read-only API tool need not share an agent session's broad write privileges.^[2]
• Credential handling is configurable. The proxy supports credential sources including system keystores, password managers, files, and host environment variables; clients can receive placeholders instead of real tokens.^[7]
• Recovery complements access control. Rollback can restore tracked local file changes after an agent makes an unwanted modification.^[8]
• Operational limits are now documented. Linux memory and task caps correct the earlier report's blanket assertion that nono has no memory limits.^[10]

---

Cautions

• Proxy injection and environment injection are different. --env-credential exposes the secret to the child. Zeroizing another process's copy does not retract a credential already handed to a workload. Proxying also does not prevent misuse of API operations that policy legitimately allows.^[7]
• The supervisor is trusted. It runs with the invoking user's permissions. Broad policies, writable executables, or an implementation flaw can undermine the intended restrictions; nono recommends an outer isolation boundary for higher-assurance and multi-tenant deployments.^[12]
• Audit is tamper-evident within a defined model. Local hashes do not prevent a host attacker rewriting a self-consistent history; signed audit roots require an independently trusted verification key. Recent proxy events may be lost if the supervisor dies before finalization.^[12]
• Platforms are not interchangeable. WSL2 behavior depends on kernel support, native Windows is unsupported, and Linux resource controls do not imply matching macOS controls.^[13][6][10]
• Pre-1.0 upgrades need review. v0.77.0 explicitly removes compatibility aliases. Pin and validate the profiles and CLI version used by a team.^[3]

---

What Developers Say

Shane Boulden's February 27, 2026 walkthrough documents using nono v0.6.0-alpha.3 with Claude Code on Fedora and OpenShift. He observed blocked paths and privilege escalation, and demonstrated audit and rollback. He also needed extra executable and device-file permissions to get that early configuration running. These are first-hand observations about that version, not proof those problems remain in v0.77.0.^[5]

The current nono site publishes favorable testimonials attributed to engineers at Datadog and Okta. They are vendor-selected testimonials, not independently verified deployment counts or a security audit. This review did not run adversarial tests or a production deployment.^[14]

---

Pricing & Licensing

Do not infer a commercial support contract, funding total, or shipped fleet-management product from the open-source runtime's availability.

---

Competitive Positioning

The useful reason to evaluate nono is its documented combination of tool-specific policies, credential routes, and audit/recovery features. This refresh does not claim it is the only tool that can hold credentials outside an agent; that earlier exclusivity claim is unsupported.^[2][7][8]

Compare requirements with Anthropic Sandbox Runtime, Fence, and yolobox, and use the local comparison to distinguish process policy from broader execution environments.

---

Ideal Customer Profile

Best fit: developers and platform teams prepared to maintain versioned policies for local agents and the tools those agents call.

Poor fit: teams expecting one default profile to fit every host, or expecting nono alone to provide hardware isolation for mutually untrusted tenants. The project's own security model makes these limits explicit.^[12]

---

Viability Assessment

The September release and repository activity support an active-development assessment. The namespace migration and breaking cleanup demonstrate that integrations still need maintenance. Repository stars and vendor-selected testimonials do not establish financial health or security assurance; the enterprise platform remains a separate, developing offering.^{[1][3][14][4]}

---

Bottom Line

nono merits evaluation for fine-grained agent and tool authority. Its value is the policy and brokering system around OS enforcement; its limitations follow from that same design. Assess the trusted supervisor, credential mode, actual kernel, and granted operations together.

Recommended for: local and embedded agent workflows that need distinct permissions for distinct tools.

Not recommended for: assuming every credential mode hides secrets, or treating process restrictions as a separate guest kernel.

Outlook: watch the 1.0 transition and test profile migrations before rollout; distinguish the available runtime from the enterprise platform under development.

---

Research by Ry Walker • methodology