--- title: How nd7 compares to nono description: A neutral comparison of documented behaviour between nd7 and nono, from nd7's competitive notes of 17 September 2026. order: 160 section: Compare --- nono is the closest comparable project to nd7, and nd7's repository keeps a note comparing the two. This page reproduces that comparison: what nono is, what it is missing from nd7's point of view, what nd7 is aiming at instead, and where nono is ahead. It is a comparison of documented behaviour, not a judgement of the product. The facts below are taken from nono's public documentation **as read on 17 September 2026**, and the framing is nd7's own, from [docs/COMPETITIVE-NOTES.md](https://github.com/nd7-dev/nd7-core/blob/main/docs/COMPETITIVE-NOTES.md). Products move; treat the date as part of the claim. One thing has already moved on nd7's side, noted at the end. The sources the note cites are nono's product site and its feature pages on audit trail and undo, its audit and atomic-rollback documentation, its enforcement internals pages on Seatbelt, Landlock and the core overview, and its repository. ## What nono is A kernel-enforced sandbox for running agents such as Claude Code, using "Landlock (Linux) and Seatbelt (macOS)" per its core overview, with composable JSON policies for filesystem and network, credential proxying with layer-7 filtering (filtering by the content of a request, not only its destination), and child sandboxes for delegated tools. Its starting point is confinement. ## Side by side, as documented Each point gives nono's documented behaviour first, then nd7's. - **Starting point.** nono: confinement. nd7: the record. - **Unit of record.** nono: a policy outcome inside a sandbox it controls — session started and ended, a capability decision, a supervisor-observed URL open. nd7: what the agent did — prompts, tool calls and results now; processes, files and network operations later. - **What a record leaf holds.** nono: the operation type, target, timestamp, and disposition (allowed or denied). nd7: the full hook payload for six typed kinds, and the whole payload for everything else. - **Evidence labelling.** nono: decisions the supervisor made. nd7: a `source` naming the evidence class — `intent:*` today, `effect:*` planned, in one timeline. - **Integrity.** nono: a hash-chain head over the ordered event stream and a Merkle root over all leaves, committed at session end, with an optional keyed DSSE signature checked by `nono audit verify`. nd7: a BLAKE3 hash chain per entry, verified by `nd7 verify`; a signature field is reserved and not implemented. - **Executable identity.** nono: only the main executable, `argv[0]` after resolution, is hashed — for `bash script.sh` this commits `/bin/bash`, not `script.sh`. nd7: not applicable in Phase 1; noted as a good idea for the effect layer. - **Storage.** nono: `$XDG_STATE_HOME/nono/audit/` with an append-only `audit-events.ndjson`, a `session.json` and an optional attestation bundle. nd7: `$XDG_STATE_HOME/nd7/sessions//` with an append-only `events.ndjson`, a chain head, a lock. - **Command line for reading.** nono: `nono audit list | show | verify | cleanup`. nd7: `nd7 verify`; no reader command, dropped deliberately. - **Undo.** nono: a baseline snapshot of all files in tracked directories before the command and a final snapshot after it, content addressed by SHA-256 and deduplicated, restored by atomic rename per file, indexed 0 and 1, with profile and `.gitignore` exclusions and retention defaults of 10 sessions or 5 GB. nd7: planned as per-operation pre-image capture, not built. - **Cross-machine sessions.** nono: not addressed in the documentation read. nd7: `session_id` and `host` are envelope fields from the first entry, for a planned phase. - **Does a record need the sandbox?** nono: the trail exists only for commands launched through nono. nd7: recording starts from hooks, needs no wrapper and no privileges. One tension the note flags in nono's own documentation: the feature page reads like an operation log, listing file reads, writes, creates and deletes, network connection attempts allowed and denied, and command executions allowed and denied, while the audit documentation page describes decision and lifecycle records. Either way, disposition — allowed or denied — is the central fact. ## What nono is missing Five gaps the note identifies, all from the documentation read on 17 September 2026. **Decisions, not operations.** nono's unit of record is a policy outcome inside a sandbox it controls: an audit event is "One recorded fact within that session, such as `session_started`, `session_ended`, a capability decision, or a supervisor-observed URL-open event." A denied action is one row; the allowed ones are where damage happens, and a decision log says what the supervisor concluded rather than what the agent did. **Per-session snapshots cannot undo one edit.** Two snapshots per session — a baseline before the command and a final one after, indexed 0 and 1 — cannot revert the third of seven edits, and cannot tell an agent's change from a concurrent human one. Service and system state, such as reloading a daemon after restoring its configuration, is outside nono's stated scope. **The trail exists only under nono.** It covers commands launched through nono and nothing else, so a session run any other way leaves no record at all. **Cross-machine sessions are not addressed.** Nothing in the documentation read covers an agent that connects to another host, so a session that leaves the machine leaves its record behind. **Executable identity stops at `argv[0]`.** "Only the main executable (`argv[0]` after resolution) is hashed. For `bash script.sh`, this commits `/bin/bash`, not `script.sh`." The script — the artefact that decides what happens — is the part not committed. ## What nd7 is aiming at instead Five differences the note sets out, in nd7's own framing. **Operations, not decisions.** nd7's unit of record is what the agent did: every prompt, tool call and result now; every process, file and network operation later. The interesting rows are the allowed ones. **Intent and effect, side by side, honestly labelled.** nd7 records what the agent said (`intent:*`) and, later, what the kernel saw (`effect:*`), in one timeline, with the log stating which is which. Disagreement between the two is itself a finding. **Per-operation undo, not per-session.** Keeping a copy of each file as it was just before each observed write — its pre-image — can revert one edit among many. Service and system state is inside nd7's stated scope, with explicit reporting of what cannot be reversed. **No sandbox required to get a record.** nd7's trail starts from hooks, needs no wrapper and no privileges, and the same log later gains kernel evidence without a format change. Enforcement, when nd7 adds it in full, is meant to be generated from recorded sessions rather than authored as profiles by hand. **Cross-machine sessions.** nd7's `session_id` and `host` envelope fields are there for this from the first entry. ## Where nono is ahead The note is explicit about this, and every point it makes is kept here. - **They enforce today.** At the time the note was written, nd7 did not, and expected not to for two phases. - **Their integrity story is more complete.** A hash chain plus a Merkle root plus a DSSE signature and a verify command is more than nd7's Phase 1 BLAKE3 chain; nd7's reserved `sig` field exists for the same reason. - **Their storage choices are sound, and nd7 made the same ones.** XDG state, append-only NDJSON for the raw event stream; nd7 arrived at both independently and says so rather than pretending otherwise. - **Executable-identity hashing** — `argv[0]` after resolution — is a good idea, and is noted for nd7's effect layer. - **They have undo today, and a reader command.** nd7 has neither. ## One thing that has changed since The note is dated 17 September 2026 and says of enforcement: "They enforce today; we do not, and will not for two phases." That has since been overtaken on nd7's side. On 21 September 2026, [ADR-0007](https://github.com/nd7-dev/nd7-core/blob/main/docs/DECISIONS.md#adr-0007-sandbox-claude-code-with-one-seatbelt-floor-and-a-trampoline-and-refuse-every-other-profile) landed a kernel-enforced sandbox for Claude Code on macOS, with rules that can be widened while a session runs. It is hand-written rather than derived from recorded sessions, which is still the stated goal, and it is macOS-only; see [How the macOS sandbox works](/docs/sandbox). Nothing else in the comparison has been re-read since the note's date, and nono's own documentation may well have moved too.