Skip to main content

Global Options

These options work with all commands.

--silent, -s

Suppress all nono output (banner, summary, status messages). Only the executed command’s output will be shown.

--theme

Select the CLI color theme for banners, summaries, warnings, and other styled output. Available themes:
  • mocha
  • latte
  • frappe
  • macchiato
  • tokyo-night
  • minimal
Resolution order:
  • --theme <NAME>
  • NONO_THEME
  • [ui] theme = "<NAME>" in ~/.config/nono/config.toml
  • default: mocha
If an unknown theme is supplied, nono falls back to mocha.

Redaction Policy

Command arguments persisted in sessions, audit logs, rollback metadata, and audit attestations are redacted with a secure default policy. You can extend the policy in ~/.config/nono/config.toml:
To stop redacting a built-in default for debugging, you must opt in explicitly:
Non-default redaction policies are recorded as a diff in audit event logs and audit attestations.

Commands

nono run

Run a command inside the sandbox.

nono shell

Start an interactive shell inside the sandbox.

nono wrap

Apply sandbox and exec into command. nono disappears from the process tree — no parent process remains. For scripts, piping, and embedding where no parent process is wanted.
nono wrap does not support proxy flags (--network-profile, --allow-domain, --credential, --upstream-proxy, --upstream-bypass). The network proxy requires a parent process. Use nono run instead.

nono proxy

Run the network-filtering / credential-injection proxy as a standalone foreground server with no sandboxed child. Prints the proxy URL, token, and HTTP(S)_PROXY exports, then blocks until Ctrl-C. Useful for pointing external workloads (containers, microVMs) at nono’s domain filtering and credential injection.
See Standalone Proxy for details.

nono why

Check why filesystem, network, scope, or command access would be allowed or denied. Designed for both human debugging and programmatic use by AI agents.

nono setup

Set up nono on this system. Verifies installation, tests sandbox support, and optionally generates example profiles.

nono profile

Create, inspect, and compare nono profiles.
Subcommands:
  • init - Generate a skeleton profile JSON file
  • list - List all available profiles (preset, pack, and user)
  • show - Show a fully resolved profile
  • diff - Diff two profiles
  • validate - Validate a profile JSON file
  • groups - List policy groups or show details for a specific group
  • schema - Print the profile JSON Schema
  • guide - Print the profile authoring guide
See Profile Introspection for full documentation of the inspection subcommands.

nono trust

Manage file attestation. Sign, verify, and manage trust for files consumed by AI agents.
Subcommands:
  • init - Create a trust-policy.json in the current directory
  • sign - Sign files
  • sign-policy - Sign a trust policy file
  • verify - Verify files against the trust policy
  • list - List files and their verification status
  • keygen - Generate a new signing key pair
  • export-key - Export the public key for a signing key

nono run Options

Directory Permissions

These flags grant recursive access to directories and all their contents.

--allow, -a

Grant read and write access to a directory.
Can be specified multiple times to allow multiple directories.

--read, -r

Grant read-only access to a directory.
Useful for source code directories that shouldn’t be modified.

--write, -w

Grant write-only access to a directory.
Useful for output directories where reading existing content isn’t needed.

File Permissions

These flags grant access to individual files only (non-recursive).

--allow-file

Grant read and write access to a single file.

--read-file

Grant read-only access to a single file.

--write-file

Grant write-only access to a single file.

Denial Prompt Control

--suppress-save-prompt

Suppress the post-run save-profile prompt for denials under a path. This does not grant access and does not remove the diagnostic footer; it only prevents the same denied path from being offered as a profile addition repeatedly.
For persistent behavior, put the same path in filesystem.suppress_save_prompt in a user profile. The older --ignore-denied spelling is accepted as an alias, but the suppress wording is preferred because this flag never turns a denial into an allow rule. When nono offers to save denied paths after a run, choosing suppress writes all listed path suggestions to filesystem.suppress_save_prompt instead of adding them as filesystem grants.

AF_UNIX Socket Permissions

These flags grant connect(2) (and optionally bind(2)) on pathname AF_UNIX sockets. Abstract-namespace and unnamed sockets are never grantable — only filesystem-backed socket paths are supported. Under restricted network modes (--block-net or --network-profile), explicit socket grants are required. A plain --allow-file/--allow grant no longer implicitly permits socket access.

--allow-unix-socket

Allow connect(2) to an existing AF_UNIX socket file. Implies read access on the socket path.

--allow-unix-socket-bind

Allow connect(2) and bind(2) on an AF_UNIX socket at this path. Use when the sandboxed program creates the socket itself. If the path doesn’t exist yet (the typical bind(2) case), the CLI auto-grants write on the parent directory so the kernel can create the socket file.
Prefer --allow-unix-socket-dir-bind for runtime-generated filenames (e.g. PID-suffixed paths) so the implied fs grant stays scoped.

--allow-unix-socket-dir

Allow connect(2) to any AF_UNIX socket directly within this directory (non-recursive — grandchildren are not covered). Implies read access on the directory.

--allow-unix-socket-dir-bind

Allow connect(2) and bind(2) on any AF_UNIX socket directly within this directory. Non-recursive. Use for runtime-generated socket filenames.
On macOS, --allow-unix-socket-dir* is enforced as direct-child-only socket access. On current Linux, pathname AF_UNIX grants are enforced through the implied Landlock filesystem directory grant, which is recursive. The direct-child distinction becomes enforceable on Linux when the seccomp AF_UNIX allowlist path is active.

--allow-unix-socket-subtree

Allow connect(2) to any AF_UNIX socket within this directory subtree (recursive — nested subdirectories are covered). Implies read access on the directory.

--allow-unix-socket-subtree-bind

Allow connect(2) and bind(2) on any AF_UNIX socket within this directory subtree. Implies read/write access on the directory.

Network Control

--block-net

Block all network access. Network is allowed by default.

--network-profile

Use a predefined network profile for host-level filtering. When set, outbound traffic is routed through a localhost proxy that only allows connections to hosts in the profile.
Available profiles: minimal, developer, claude-code, codex, opencode, enterprise. See Networking for details.
--network-profile and --allow-domain activate proxy mode, which forces supervised execution. The proxy runs in the unsandboxed parent process.

--allow-domain

Add a domain to the proxy allowlist. Can be specified multiple times. Activates proxy mode if not already active. This flag only permits HTTP(S) traffic routed through nono’s proxy. It does not grant direct raw TCP access to the destination port. Accepts either a plain hostname (unrestricted access to all paths) or a URL with a path glob pattern (restricts to matching paths only):
When a URL with a path is provided, only requests matching that path pattern are permitted. Requests to other paths on the same domain are denied with 403 Forbidden. Pattern syntax: * matches one path segment, ** matches zero or more.

--deny-domain

Block a domain through the proxy even if it would otherwise be allowed. Can be specified multiple times. Activates proxy mode if not already active. Deny rules are evaluated before the allowlist, so a domain in both --deny-domain and --allow-domain (or a network profile) is always blocked. Accepts a plain hostname or a wildcard subdomain pattern:
Wildcard syntax (*.example.com) matches subdomains but not the bare domain itself. Cloud metadata endpoints (169.254.169.254, metadata.google.internal, etc.) are always denied regardless of this flag. Incompatible with --allow-net (which bypasses the proxy entirely, making deny rules ineffective).

--credential

Enable credential injection for a named service via the reverse proxy. The service must be either a preset service (openai, anthropic, gemini, google-ai) or defined as a custom credential in your profile. Credentials are loaded from the system keyring under the nono service name, from 1Password when credential_key is an op:// URI, from Apple Passwords on macOS when credential_key is an apple-password:// URI, from a file when credential_key is a file:// URI, or from the host environment when credential_key is an env:// URI.
The proxy sets OPENAI_BASE_URL, ANTHROPIC_BASE_URL, etc. in the child environment so SDKs route through the proxy automatically. Custom credentials can be defined in profiles for APIs not covered by the preset services:
See Credential Injection for complete documentation including custom credential definitions.

--allow-endpoint

Restrict a credential service to specific HTTP method+path patterns. When set, only requests matching at least one rule are proxied; all others receive 403 Forbidden. Can be specified multiple times. Format: SERVICE:METHOD:PATH
  • SERVICE: credential service name (e.g., openai, github)
  • METHOD: HTTP method (GET, POST, etc.) or * for any method
  • PATH: URL path glob pattern (* matches one segment, ** matches zero or more)
Endpoint rules can also be defined in profiles via endpoint_rules on custom credentials. See Networking — Endpoint Filtering for details.

--upstream-proxy

Chain outbound connections through an upstream (enterprise) proxy. Cloud metadata endpoints are still denied.

--upstream-bypass

Route specific domains directly instead of through the upstream proxy. Supports exact hostnames and *. wildcard suffixes (case-insensitive). Requires --upstream-proxy.
Bypass hosts are checked before routing. Matching hosts use a direct CONNECT tunnel; non-matching hosts chain through the upstream proxy. Can be specified multiple times.

--proxy-port

Set a fixed port for the credential injection proxy (default: OS-assigned ephemeral port). Use this when the sandboxed application requires a known proxy port that can’t be configured via environment variables.
Without --proxy-port, nono uses an OS-assigned ephemeral port and sets environment variables like GEMINI_BASE_URL=http://127.0.0.1:PORT/gemini. Applications that read these env vars don’t need --proxy-port. Use it only when the application requires manual base URL configuration.

--trust-proxy-ca

macOS only. Add the proxy’s TLS interception CA to the macOS user trust store via Keychain. This enables Go CLI tools (gh, terraform) that ignore SSL_CERT_FILE and only verify certificates via the system trust store (com.apple.trustd).
The CA is persisted in macOS Keychain and shared across sessions. It regenerates automatically when expired (default: 1 day, configurable via --proxy-ca-validity):
  • First run: Generates a new ECDSA P-256 CA, stores it in Keychain, and adds it to the user trust store (one biometric/password prompt)
  • Subsequent runs: Loads from Keychain with zero prompts
  • After expiry: Removes the expired CA and regenerates
This flag has no effect without --credential (or another TLS-intercepting route). If no credential routes are configured, nono warns and skips CA generation.
Environment variable: NONO_TRUST_PROXY_CA=1

--proxy-ca-validity

Set the ephemeral proxy CA certificate validity in days (1–365, default: 1). Leaf certificates minted for intercepted hosts share the same expiry as the CA.
When used with --trust-proxy-ca, the validity only applies when generating a new CA. An existing Keychain CA that is still valid will be reused regardless of this setting.
Environment variable: NONO_PROXY_CA_VALIDITY=<days>

--listen-port

Allow the sandboxed process to listen on a TCP port. Required when running server applications (like AI gateways) in proxy mode.
macOS limitation: Seatbelt cannot filter by port number. When --listen-port is specified on macOS, the sandbox permits binding to any port and accepting inbound connections from any source.This is a broader permission than intended, but the security impact is limited:
  • Outbound connections are still restricted to allowed hosts via the proxy
  • Filesystem access is still limited to granted paths
  • An attacker would need to know the machine’s IP and which port the agent opened
  • Even if they connect, they can only send data in — the agent cannot exfiltrate responses to arbitrary hosts
On Linux with Landlock ABI v4+, per-port filtering is enforced and only the specified ports can be bound.
--listen-port only has effect in proxy mode (when --network-profile or --allow-domain is active). Without proxy mode, network operations use the default OS-level allow/deny and bind is not restricted.

--open-port

Allow bidirectional localhost TCP on a specific port. The sandboxed process can both connect to and bind/listen on 127.0.0.1:<PORT>. Use this for IPC between sandboxed processes (e.g., MCP servers, dev tools, AI agents running in separate sandboxes).
Works across all network modes:
  • --block-net: The port becomes an exception to the block (localhost only)
  • Proxy mode: The port is allowed in addition to the proxy port
  • Default (AllowAll): No-op — all ports are already reachable
Can be specified multiple times for multiple ports.
macOS limitation: Seatbelt cannot filter bind/inbound by port number. When --open-port is specified on macOS, the sandbox permits binding to any port (same tradeoff as --listen-port). Outbound connections are still restricted to only the specified localhost ports.Linux limitation: Landlock ABI v4+ enforces both connect and bind per-port, but cannot filter by destination IP. The ConnectTcp rule allows connecting to the specified port on any IP, not just localhost. In practice this is mitigated by using --block-net (which blocks all outbound except the allowed ports) or proxy mode (which routes outbound through the localhost proxy). Only the --open-port + default AllowAll combination (a no-op) would theoretically permit non-localhost connections on the port.

Resource Limits

--memory

Cap the resident memory of the sandboxed process tree. If the tree goes over, the Linux kernel kills the whole sandbox at once (the run exits 137) and nono prints a diagnostic naming the limit and the peak the tree reached.
Sizes take an optional unit suffix: 512M/512MiB (binary, 1024-based), 512MB (decimal, 1000-based), and K/G/T likewise; a bare number is bytes.

--max-processes

Cap how many processes and threads (tasks) the sandboxed tree may have alive at once. Unlike the memory cap, hitting it kills nothing — the kernel refuses the next fork/clone with EAGAIN. This bounds fork bombs and runaway spawning.
The value is a plain count (minimum 1) and counts threads as well as processes, so leave headroom for the threads your workload uses. Combine it with --memory freely. Both resource flags share the same enforcement path:
  • Linux only, enforced via cgroup v2 (memory.max / pids.max), and requires a systemd Delegate=yes user session with the relevant controller (memory / pids) delegated. Otherwise the request is refused rather than silently ignored.
  • Enforced on nono run and nono shell (supervised). nono wrap execs directly and does not accept --memory or --max-processes.
  • Granting the sandbox write access overlapping /sys/fs/cgroup (e.g. --allow /sys) is refused while a resource limit is active, since it would let the process rewrite its own cap. Use --read /sys instead if a workload needs it.
See Resource Limits for the full details.

nono shell Options

nono shell supports the same permission, profile, credential, and dry-run flags as nono run, plus:

--shell

Override the shell binary.

Command Blocking

--allow-command

Deprecated in v0.33.0. Allows a normally-blocked startup command, but only for the directly-invoked executable. Child processes can bypass this check, so it should not be treated as a sandbox security boundary.
--allow-command and the default command blocklist are startup-only checks. They do not prevent child processes, interpreters, language runtimes, shell built-ins, renamed binaries, or equivalent APIs from performing the same operation. For hard protection, rely on kernel-enforced path and network controls such as deny.access, deny.unlink, narrower filesystem grants, and network policy.
Commands can also be allowed temporarily via the deprecated commands.allow field (the older security placement is also accepted with a deprecation warning, see issue #594):

--block-command

Deprecated in v0.33.0. Adds a startup-only command denylist entry for the directly-invoked executable. Child processes can bypass this check.

Deny Group Overrides

--bypass-protection

Bypass a deny group rule for a specific path. Required groups like deny_credentials block access to paths such as ~/.aws, ~/.config/gcloud, etc. This flag punches a targeted hole through the deny without removing the entire group. The bypass path must also be explicitly granted via --allow, --read, --write, or their file equivalents. --bypass-protection only removes the deny rule — it does not implicitly grant access.
Can be specified multiple times.
Security guardrails:
  • A warning is printed to stderr for each bypass applied, making security relaxations visible in logs.
  • On macOS, Seatbelt allow rules more specific than the deny are emitted. On Linux, the deny path is removed from validation so Landlock allow rules take effect.
--bypass-protection without a matching grant (--allow, --read, --write, etc.) is a hard error. This prevents silent no-ops on Linux and unintended implicit grants on macOS.
Renamed in issue #594. This flag was renamed from its former deny-override name. The legacy name is still accepted as a deprecated alias and emits a warning on use; it will be removed in v1.0.0.

Credential Options

--env-credential

Load credentials from the system keystore (macOS Keychain / Linux Secret Service) by account name and inject them as environment variables. The sandboxed process can read these credentials directly.

--env-credential-map

Map an explicit credential reference to a destination environment variable. Repeatable as --env-credential-map <CREDENTIAL_REF> <ENV_VAR>.
Credentials are:
  • Loaded before the sandbox is applied (keystore access blocked after)
  • Auto-named by uppercasing for keyring names: openai_api_key becomes $OPENAI_API_KEY
  • --env-credential-map validates URI references (op://, apple-password://, env://) and target env var names
  • --env-credential URI suffix form remains supported for 1Password compatibility (op://...=VAR)
  • Zeroized from memory after exec()
For network API keys, prefer --credential instead for credential isolation — the agent never sees the real API key. See Credential Injection for full documentation on storing and using credentials.

Profile Options

--profile, -p

Use a named profile (from installed packs or ~/.config/nono/profiles/).

--extends

Extend the selected profile with an additional base profile for one invocation. Repeatable; bases are merged left-to-right, then any extends already in the selected profile is resolved, and the selected profile remains the final override layer.
This is equivalent to temporarily prepending those bases to the profile JSON’s extends field. It requires --profile and conflicts with --config. Inherited filesystem and network grants can widen sandbox permissions, so treat each base profile as explicit policy input.

--workdir

Working directory for $WORKDIR expansion in profiles (defaults to current directory).

--allow-cwd

Allow access to the current working directory without prompting. By default, nono prompts interactively for CWD sharing. The access level is determined by the profile’s [workdir] config or defaults to read-only.

--allow-launch-services

Allow direct LaunchServices opens on macOS for this session. This is intended for temporary login or setup flows that need to open a browser from inside the sandbox.
--allow-launch-services is only supported on macOS. It requires the selected profile to opt into allow_launch_services and configure open_urls; otherwise nono fails closed with an error.

--allow-gpu

Allow GPU compute access for workloads like ML inference and shader compilation.
  • macOS (Apple Silicon): Grants scoped IOKit access for Metal GPU compute (IOGPU, AGX, IOSurface). Intel Macs are not yet supported.
  • Linux: Grants access to DRM render nodes (/dev/dri/renderD*), NVIDIA compute devices (nvidia[0-N], nvidiactl, nvidia-uvm), NVIDIA MIG caps, AMD KFD (/dev/kfd), and WSL2 DirectX passthrough (/dev/dxg). Also grants read-only access to Vulkan ICD manifests and GPU sysfs.
When used with a profile, the profile must opt into allow_gpu; otherwise nono fails closed with an error. Without a profile, the CLI flag alone is sufficient.

--allow-http2

Enable HTTP/2 multiplexing for upstream proxy connections. When set, the proxy negotiates h2 via ALPN with upstreams that support it, and the CONNECT intercept advertises both h2 and http/1.1.
Without this flag, the proxy uses HTTP/1.1 with keep-alive connection pooling. This is the conservative default since some upstream servers may not handle HTTP/2 correctly. See Networking — HTTP/2 Support for details on connection pooling and profile configuration.

Execution Mode Flags

--detached

Start the supervised session without attaching the current terminal. The command keeps running in the background and can be resumed later with nono attach <session>.
Detached launches print the generated session ID and the attach command once the session becomes ready.

--detach-timeout

How long (in seconds) to wait for a detached session to become attachable before giving up. Defaults to 30 seconds. Increase this for programs with slow startup (e.g. npm/network initialisation phases).

--name

Assign a human-friendly name to the supervised session. The name is shown in nono ps and can be used to recognize the session in later attach, stop, logs, and inspect workflows.
Session names must be unique among live sessions. If you omit --name, nono generates a unique name automatically.

--rollback

Enable atomic rollback snapshots for the session. Takes content-addressable snapshots of writable directories so you can restore to the pre-session state after the command exits. Automatically selects supervised execution.

--no-rollback-prompt

Suppress the interactive post-exit review when using --rollback. Snapshots are still taken but the user is not prompted to review or restore changes. Useful for scripting.

--no-rollback

Disable rollback entirely for this session. No snapshots are taken and no restore is offered. Useful when rollback overhead is not needed.

--no-audit

Disable the audit trail for this session. By default, every supervised execution records session metadata and audit events (command, timestamps, exit code, capability decisions, URL opens, network events) to $XDG_STATE_HOME/nono/audit/ (default ~/.local/state/nono/audit/). Use this flag to suppress audit recording entirely.
--no-audit conflicts with --audit-integrity. Integrity metadata is computed from the audit event stream.

--audit-integrity

Enable append-only integrity metadata for the audit log. nono writes an audit-events.ndjson stream in session order, hashes each event into a leaf, maintains a running chain head, and stores a final Merkle root in the session metadata. This provides tamper evidence for the recorded audit log without enabling filesystem snapshots. Audit flags control three different layers:
  • Session audit Record what happened during one nono run.
  • Audit-log integrity Make the recorded audit event log tamper-evident with a hash chain and Merkle root.
  • Filesystem integrity Hash the tracked writable filesystem state before and after the run.
The modes are:
  • Default Session audit + audit-log integrity
  • --no-audit Disable audit recording completely
  • --no-audit-integrity Keep the session audit, but disable the event-log integrity layer
  • --audit-integrity Keep the default audit behavior and also add filesystem-state hashing
  • --rollback Keep all of the above and also store rollback snapshots for restore
--audit-integrity adds filesystem-state hashing for the tracked writable paths. --rollback is still the feature that stores full restoreable snapshots.

--audit-sign-key

Sign the completed session audit record with a keyed signing key loaded by the supervisor. This happens once per session, after the run ends. It does not sign every event individually. The supervisor:
  1. records audit events during the session
  2. computes the session’s final audit Merkle root
  3. signs that final root plus redacted session context
  4. writes the resulting keyed DSSE attestation to audit-attestation.bundle
A summary is also recorded in session.json. Accepted secret references:
  • bare trust key IDs, for example default
  • keystore://name
  • file:///absolute/path
  • op://vault/item/field
  • apple-password://server/account
  • keyring://service/account
  • env://VAR_NAME
The corresponding attestation can be pinned during verification:
--audit-sign-key signs the session audit Merkle root and session context once, after the session completes. Command arguments in that context are best-effort redacted for common secret-bearing flags, headers, and URLs. This does not, by itself, add an external timestamp, Rekor entry, or full runtime-closure attestation.

--rollback-exclude

Exclude from rollback snapshots. Repeatable. Values containing glob characters (*, ?, [) are matched against filenames. Plain names match exact path components; names with / match as path substrings. Does NOT affect sandbox permissions — excluded directories are still sandboxed.

--rollback-include

Force-include a directory in rollback snapshots that would otherwise be auto-excluded. Repeatable. Accepts directory names (e.g., target, node_modules), not full paths. Use when you need rollback coverage on build artifacts or dependencies.
nono automatically excludes known regenerable directories (.git, target, node_modules, etc.) and any directory with more than 10,000 files from rollback snapshots. This prevents rollback from hanging on large projects. Use --rollback-include to override for specific directories or --rollback-all to disable all auto-exclusions.

--rollback-all

Include ALL directories in rollback snapshots, overriding all auto-exclusions. This may be very slow on large projects with build artifacts.

--skip-dir

Skip a directory name during pre-exec trust scanning and rollback preflight. Repeatable. Matches exact path components, not full paths. This is useful for large generated trees that are safe to exclude in your workflow.
--skip-dir does not change sandbox permissions. It only prunes trust discovery and rollback preflight traversal. Hidden directories are still scanned unless they are in the built-in heavy-dir list or explicitly named here.

--startup-timeout

Set a startup timeout in seconds for the sandboxed process. If the process does not appear interactive within the given time, nono prints a warning and terminates it. Entering alt-screen or writing visible non-whitespace output both count as interactive. Set to 0 to disable entirely. Applies to nono run and nono shell. Not available on nono wrap (which uses direct exec with no supervisor).
No timeout is applied by default. When a known built-in profile exists for the binary (e.g. opencode, claude), the warning message also suggests the recommended profile.

--no-diagnostics

Suppress the diagnostic footer when the command exits non-zero. Useful for scripts that parse stderr and need stable output.
On macOS, to hide specific expected Seatbelt violations (such as user-preference-read from npm) without silencing all diagnostics, add the operation name to diagnostics.suppress_system_services in your profile instead. See Profiles and Groups.

--capability-elevation

Enable runtime capability elevation for this session. When active, the sandbox installs a seccomp-notify filter (Linux) and a PTY multiplexer so that file access beyond the initial capability set can be approved interactively at runtime.
Without this flag (the default), the sandbox runs with static capabilities only — no interactive approval prompts, no seccomp interception, and no PTY mux. The supervisor still runs for trust interception and rollback support. Profiles can set this via capability_elevation in their security config. The CLI flag overrides the profile setting.

--sandbox-policy

Linux only. Select the sandbox enforcement mechanism for this session. Accepted values:
The policy can also be set in a profile under linux.sandbox_policy. The CLI flag overrides the profile value. This setting is supported only by nono run; nono shell and nono wrap reject profiles that contain linux.sandbox_policy. On macOS and other non-Linux platforms this flag is not available.
--sandbox-policy landlock is useful for compliance contexts where you need a hard guarantee that seccomp BPF is not installed, or where you want to verify that the target kernel’s Landlock ABI is sufficient before deploying to production.
--sandbox-policy external provides no nono-managed TCP egress lockdown. Only use it when you have independently verified that the surrounding infrastructure forces outbound traffic through the intended proxy.

Operational Flags

--dry-run

Show what capabilities would be granted without actually executing the command or applying the sandbox.
Output:
On Linux, combine --dry-run with -v to include detected Landlock ABI details and requested/enforced scope state:

--verbose, -v

Increase logging verbosity. Can be specified multiple times.

--trust-override

Disable trust verification for instruction files. Skips the pre-exec trust scan that verifies cryptographic signatures on instruction files (SKILLS*, CLAUDE*, AGENT*, .claude/**/*.md). For development and testing only.
Using --trust-override in production is not recommended. It disables the entire instruction file attestation pipeline, allowing unsigned or tampered instruction files to be read by the sandboxed process.

--config, -c

Specify a configuration file path.
Configuration file support is planned for a future release.

--help, -h

Print help information for the command.

nono why Options

The why command checks why filesystem, network, scope, or command access would be allowed or denied. It’s designed for both human debugging and programmatic use by AI agents.

--command

Tool-sandbox command name to check against Tool Sandbox command policy. Pass the command arguments after --.

--caller

Command-policy caller edge to evaluate. Defaults to session, which is the usual caller for a tool invoked directly from the sandboxed agent session.

--path

The filesystem path to check.

--op

The operation to check: read, write, or readwrite. Defaults to read if not specified.

--host

Network host or URL to check (instead of --path). Accepts a bare hostname or a full URL with a path to check endpoint rule matching.

--port

Network port (default: 443). Used with --host.

--scope

Landlock scope to check. Supported values are signal and abstract-unix-socket.
On Linux, scope queries report whether the effective capability set requested the scope, whether the detected Landlock ABI can support it, and whether nono will enforce it. On non-Linux platforms, scope queries return not_applicable.

--json

Output JSON instead of human-readable format. Useful for programmatic use by AI agents.

--self

Query current sandbox state from inside a sandboxed process. This allows agents to introspect their own capabilities.

Capability Context Options

When checking paths outside a sandbox, you can simulate a capability context:
Available context flags:
  • --allow, -a - Directories with read+write access
  • --read, -r - Directories with read-only access
  • --write, -w - Directories with write-only access
  • --allow-file - Single files with read+write access
  • --read-file - Single files with read-only access
  • --write-file - Single files with write-only access
  • --block-net - Block network access
  • --allow-net - Force unrestricted network access for this run
  • --profile, -p - Use a named profile
  • --extends - Add repeatable base profiles to the selected profile for this query (requires --profile)
  • --workdir - Working directory for $WORKDIR expansion

nono trust Options

nono trust init

Create a trust-policy.json in the current directory. Scans for files and auto-populates patterns and publisher.
File discovery for init respects .gitignore to keep the generated policy clean. Hidden directories like .claude/ and .github/ are included. Common build artifact directories (node_modules, target, .venv, etc.) are skipped by default. Note: the pre-exec trust scan and sign --all/verify --all do not respect .gitignore — adding a file to .gitignore cannot bypass trust verification.

nono trust sign

Sign files, producing bundles for verification.
When signing multiple files, a single .nono-trust.bundle multi-subject bundle is created. Single-file signing creates per-file .bundle sidecars.

nono trust sign-policy

Sign a trust policy file.

nono trust verify

Verify instruction files against the trust policy.

nono trust list

List instruction files and their verification status.

nono trust keygen

Generate an ECDSA P-256 signing key pair.

nono trust export-key

Export the public key for use in trust policy public_key fields.

nono setup Options

--check-only

Only verify installation and sandbox support, don’t create any files.

--profiles

Generate example user profiles in ~/.config/nono/profiles/.

--shell-integration

Show shell integration instructions (aliases, etc.).

--verbose, -v

Show detailed information during setup. Can be specified multiple times.

Exit Codes

Path Resolution

All paths are canonicalized before the sandbox is applied:
  • Relative paths are resolved to absolute paths
  • Symlinks are followed and resolved
  • Parent directory references (..) are resolved
This prevents symlink escape attacks where a malicious agent creates a symlink pointing outside the allowed directory.

Combining Flags

Flags can be combined freely:

Environment Variables

Several CLI flags can be set via environment variables. This is useful in CI/CD pipelines, container entrypoints, and wrapper scripts where setting env vars is more natural than modifying command arguments. CLI flags always take precedence over environment variables. Boolean variables accept true, false, yes, no, 1, 0. Conflict rules apply equally whether the value comes from a flag or an environment variable. For example, setting both NONO_ALLOW_NET=true and NONO_BLOCK_NET=true is an error, just like passing both --allow-net and --block-net.

Existing environment variables

Timeout tuning

These environment variables override internal timing defaults. They have no CLI flag equivalents and are only needed when the defaults cause problems for specific workloads. Invalid values are ignored with a warning and the default is used.

Examples

See the Examples page for common usage patterns.