Test Nono 0.70 by control path, not by release tag

nono v0.70.0 gives teams a more precise way to restrict what coding and workflow agents can do with files, commands, network routes, and credentials. The stakes are practical: a sandbox can enforce one route well while an approval or audit route remains unclear, so a release-level verdict can hide the part that a production workflow depends on.

This article explains which v0.70.0 controls are ready for a pinned evaluation, where their enforcement stops, and which combinations should wait. Teams can test predeclared policy and proxy-mediated credentials now. They should not make dynamic capability elevation, its audit trail, or network.block with open_urls a production dependency until the open behavior is resolved, documented, and retested.

Nono 0.70 is a normal release in a pre-1.0 project

The nono project published its v0.70.0 release on GitHub at 15:01:22 UTC on July 29, 2026. The release is not marked as a draft or prerelease. The project README, however, says its APIs are still stabilizing before 1.0 and can change when necessary. A normal release tag and a pre-1.0 maturity warning can both be true.

The project is Apache-2.0 and names macOS, Linux, and Windows through WSL2 as supported environments. The v0.70.0 release assets include Linux and Darwin builds, but no native Windows build. An independent category overview describes nono's use of Landlock on Linux, Seatbelt on macOS, and stand-in credentials, but it predates v0.70.0 and does not test this release.

The change history also needs careful reading. The release body links to a changelog that starts at v0.68.0, so its feature list is not a clean v0.69.0-to-v0.70.0 delta. GitHub's narrower comparison reports a diverged history with 35 commits ahead and one behind. The useful adoption evidence therefore comes from the specific merged changes and their stated limits, not from the length of the release note.

No independent security audit or production benchmark of v0.70.0 was found. Teams must therefore treat project-described tests as evaluation evidence only.

Predeclared policy gives teams the clearest place to start

A sandbox sets an external limit on what an agent process can reach. The broad case for moving filesystem, network, process, and inference controls outside the model is already established in our OpenShell runtime analysis. For an adoption decision, the next question is narrower: which exact nono path enforces each limit?

Predeclared policy is the simplest path because the team sets it before the process starts. A nono configuration can describe filesystem access, network access, credentials, and rules for the tools an agent invokes. The agent can request work, but it cannot give itself a file grant or real secret that the policy does not provide.

This is a useful starting point for teams that have already defined the runtime powers agent-written code may use. Pin v0.70.0, give one workflow only the files, commands, and destinations it needs, then attempt both allowed and denied actions. A pass requires evidence that the expected work succeeds and that the denied work fails in the expected place.

Per-route rate limits work only on traffic Nono can read

The per-route rate-limit change adds an optional token bucket to a proxy route. A token bucket allows requests while tokens are available and refills them at a configured rate. When the bucket is empty, nono delays the request for no longer than the configured maximum and then returns HTTP 429 instead of waiting without a bound.

This control depends on Layer 7, or L7, visibility. L7 is the application layer, where a proxy can read details such as an HTTP destination, method, and path. Nono applies the limiter to its reverse-proxy route and intercepted CONNECT traffic because those paths expose enough application information to identify the route.

An opaque CONNECT tunnel does not expose that information to the limiter and is outside its scope. A team evaluating rate limits must therefore prove that the agent's traffic uses a visible route. A configured limit that cannot see the traffic is not an active limit.

The bounded delay and HTTP 429 behavior are useful because they give the caller a defined failure. Teams should test normal traffic, an empty bucket, the maximum delay, and the caller's response to 429. If the agent retries without its own bound, a sound proxy response can still become a noisy workflow failure.

Credential mediation can keep the real Vault token outside the sandbox

Credential mediation separates the value an agent holds from the real secret that reaches an approved service. The sandbox receives a stand-in, sometimes called a phantom credential. A trusted proxy outside the sandbox replaces that value with the real credential only when an allowed request leaves through the correct route.

The merged Vault OIDC implementation applies that mechanism to vault login -method=oidc. The project says the OIDC callback captures the real Vault token outside the sandbox, puts a phantom token inside, and redeems the phantom when traffic exits to the Vault API. The change also handles Vault's X-Vault-Token header and a per-command callback port.

This is a project implementation claim backed by tests described with the change, including an end-to-end test against Vault. It is not an independent audit. A local evaluation should still prove that the real token is absent from the sandbox's environment, files, command output, and logs, and that redemption fails for an unapproved host, method, or path.

The benefit is specific. If the mediation works as described, a compromised tool can hold a usable stand-in without receiving the reusable Vault token. The proxy route, endpoint policy, secret store, and logs remain part of the trusted path and need owners of their own.

Adjacent controls need separate tests because their combinations change behavior

Two v0.70.0 corrections show why a team must test the final policy combination. The upstream-proxy correction makes nono reject an upstream proxy when hard network blocking is enabled. Earlier behavior could let proxy semantics silently take precedence over the hard block.

The credential and host-filter correction addresses a different interaction. A custom credential's upstream host could activate host filtering when no other host filter was configured, which changed an allow-all policy into an allow-only-that-upstream policy. The correction adds that host only when filtering is already active.

Both corrections narrow ambiguous behavior, which is useful. They also show that filesystem policy, network mode, proxy routing, credential injection, and host filtering do not operate as independent switches. The team must test the assembled configuration and observe what the agent, proxy, supervisor, and audit output each report before enforcement affects real work. Our observe-before-enforce guidance explains why that sequence matters when a control can block legitimate traffic.

Dynamic elevation and its audit path remain unresolved production dependencies

Capability elevation is a runtime request for authority that the original sandbox policy did not grant. A process might request read access to a new file, after which a person or approval service grants, denies, or lets the request time out. This path is harder to depend on because the approval display, decision, enforcement result, and audit record must agree.

An open Linux v0.70.0 report says elevation requests affect the sandbox result but their approvals, denials, and timeouts do not appear in nono audit show. The only response at the time of publication is automated bot triage that explicitly says it is not a maintainer decision. This is a reporter claim, not a confirmed vulnerability, but an absent decision record would be material for any workflow that relies on approval evidence.

A second open Linux v0.70.0 report describes corrupted interactive terminal output when standard input and output use a TTY. A TTY is the interactive terminal interface that carries the approval request and the user's response. A later comment reports similar display symptoms on macOS with Claude Code, but it uses nono v0.69.0 and a different command-policy approval path. A maintainer asked for more details; the thread does not establish one reproduced v0.70.0 defect across both paths or a released fix.

The open network.block and open_urls discussion has a different status. The reporter expected a host-mediated URL open to remain allowed while the sandbox's outbound network stayed blocked. A maintainer replied that rejection seems like the right behavior at present and asked for the use case. Teams should treat this combination as disputed or undefined for their purpose, not as a confirmed bug.

These reports do not show that all dynamic approval paths fail. They do show that a production design should not depend on elevation, its audit trail, or the blocked-network URL combination until the project defines the intended behavior and a pinned retest proves it in the team's environment.

A pinned evaluation should prove enforcement and failure behavior separately

Start with one real workflow in a disposable environment and pin nono v0.70.0. Give the workflow a predeclared filesystem, command, and network policy. Run expected work, denied work, malformed commands, unavailable services, and timeouts, then compare the visible result with the audit output. The policy owner should be able to explain which component made each decision.

Next, test one L7-visible proxy route with a low temporary rate limit. Confirm the delay bound, HTTP 429 response, and retry behavior. Then test the same destination through any tunnel mode the workflow can use. The result should show whether the rate limiter sees every route that the production design expects it to govern.

For mediated credentials, use a non-production Vault role with narrow permissions. Confirm that the real token stays outside the sandbox, the phantom works only through the intended egress route, and denied destinations never receive the secret. Inspect logs on both sides so that observability does not reintroduce the credential exposure the proxy is meant to prevent.

Run capability elevation as a separate diagnostic test. Exercise approve, deny, and timeout behavior; use the actual terminal and agent interface planned for deployment; and check whether each decision appears in nono audit show. Test network.block with open_urls separately and record the observed semantics, but do not widen production authority to work around an unresolved combination.

Adopt the proven paths and hold the disputed paths back

Teams should use nono v0.70.0 as a pinned evaluation target for predeclared filesystem, network, and command policy, plus proxy-mediated credentials that they can test end to end. The release adds a bounded per-route limiter and a concrete Vault OIDC mediation path, while also correcting policy interactions that could otherwise change the effective network boundary.

Dynamic capability elevation needs a higher bar because its approval interface and evidence path are part of the control. Keep elevation, elevation audit records, and network.block with open_urls out of production dependencies until the relevant behavior is resolved, documented, and retested on the exact operating system, terminal, agent, and policy combination the workflow will use.

For a team that needs to turn one agent workflow into a bounded production decision, BaristaLabs process automation services can help test the filesystem, network, command, credential, approval, audit, and failure paths before access expands.