At a glance. Two related Hermes contributions tightened the evidence required before Nono diagnostics recommend a permission change. Nono #1816 gates path and network guidance on relevant observed evidence. Nono Packs #29 separately asks whether Nono, rather than some other subsystem or sandbox, actually caused the denial. Both merged on 9 September 2026. The Nono core correction is contained in the v0.76.0 release by verified commit ancestry; this does not establish a corresponding release for the separate packs repository. [S1–S4]
What happened
A diagnostic footer could suggest path or network grants even when the recorded session contained no evidence that those permissions caused the failure. That presentation made application and system-service errors appear actionable through unrelated sandbox changes. The core contribution corrected the recommendation boundary without changing enforcement. [S1]
The packs contribution addressed a related but narrower causal question. A generic permission error is not an attribution to Nono. Even a marker showing that a sandbox participated does not identify which sandbox enforced the denial. Guidance that moves straight from a familiar error string to a Nono-specific remedy skips that distinction. [S2]
When it happens
The affected core surface is diagnostic guidance. Path evidence, logged denials, stderr path hints, missing paths and real network blocks must remain distinguishable. The change preserves remedies justified by those observations while withholding unrelated guidance. It leaves sandbox enforcement, capabilities, policy resolution and diagnostic records unchanged. [S1]
The packs change spans twelve guidance files. It distinguishes Nono provenance from generic EPERM, EACCES, "Permission denied" and "Operation not permitted" messages, and from generic sandbox-enforcement markers such as Landlock or a nested execution sandbox. These are observations about an error or an enforcement mechanism, not conclusive identification of Nono as its cause. [S2]
Reproduction and positive controls
For the core change, the important regression is an unsupported recommendation: a session without relevant path or network-denial evidence must not receive the corresponding grant guidance. Positive controls preserve the useful advice for recorded denials and the already-supported path and network situations. [S1]
For packs, the recorded red-before assertions expose guidance that inferred the wrong authority from insufficient evidence. Green-after assertions check the provenance and status requirements across all twelve corrected files. These are tests of guidance content and branch behavior, not an experiment measuring users' willingness to widen permissions. [S2]
| Evidence available | Conclusion the revised guidance can support |
|---|---|
| Generic permission error only | Investigate the source; Nono-specific causation is not established |
| A generic sandbox-enforcement marker | A sandbox may be involved; its identity still needs evidence |
| Output specifically naming Nono as the relevant boundary | Nono provenance can be established in the documented context |
Successful Nono self-diagnostic with status DENIED | Confirms the Nono boundary for the diagnosed path |
| No confirming Nono evidence | Preserve the non-sandbox diagnostic route instead of forcing a Nono remedy |
What we observed
The core correction and the packs correction answer different questions. The first asks, "Is there relevant evidence for this kind of recommendation?" The second asks, "Does the evidence identify this system as the cause?" Keeping both questions explicit prevents a broad permission string from silently becoming a specific configuration instruction. [S1, S2]
An important precision: packs #29 does not make one command result the only possible provenance route. Its summary permits output naming Nono or a successful nono why --self result whose status is DENIED. For a concrete path, the self-diagnostic is the documented confirmation route, including ordinary path_not_granted results without a policy source. [S2]
Why it happens
Error messages often identify a symptom at a different level from the remedy being recommended. A permission failure describes a denied operation. A Nono-specific remediation additionally assumes which policy boundary denied it and which configuration would address it. Those assumptions require evidence of their own.
The practical failure is therefore an evidence-to-action mismatch, not simply an inaccurate label. An unsupported diagnosis can direct a user toward an unnecessary permission change. The contributions narrow what the guidance recommends; they do not demonstrate exploitation, quantify downstream security risk or prove that the sandbox had been bypassed. [S1, S2]
Resolution and current remediation
Nono #1816 adds evidence gates to the diagnostic recommendations. Path grant and path-diagnostic advice require path evidence, while network-grant advice requires network-denial evidence. Existing relevant remedies remain. The merge commit is 00b4086f8b27db8227a2251df921f5c478f0b69b. [S1]
Nono Packs #29 adds the provenance distinction, keeps an explicit non-sandbox outcome when Nono is not confirmed, and stops inferring active profiles across the affected guidance. Confirmed denials retain their existing narrow remediation paths. Its separate merge commit is 0ade4b15a8a2dad932a091a5ec7e983b1a02378a. [S2]
The core v0.76.0 release was published on 9 September 2026. A comparison from the core merge commit to that tag returns the same commit as its merge base, establishing that the tagged history contains the correction. This supports "included in v0.76.0," not "v0.76.0 was proved to be the first fixed version," and not a binary-level revalidation of every release asset. [S3, S4]
Verification
The core PR records focused regression and positive-control coverage for the evidence-gated branches. Its public body does not supply a total passing-test count, so this report does not invent one. [S1]
The packs PR records red-before content assertions, green-after checks across twelve files, parsing of every package manifest and verification of declared artifact paths, parsing of the Codex wiring TOML, whitespace validation and a passing Hermes Gate fast receipt. That is evidence for the modified guidance and package structure, not a new evaluation of all supported agents in live use. [S2]
The editorial pass reread the primary PR metadata and checked the core release ancestry. It did not rerun the Rust or pack validation, execute a sandbox experiment or test installed binaries.
Consequences and follow-on work
The core correction merged at 09:20:10 UTC on 9 September; the packs correction followed at 09:27:17 UTC. The core release was published later that morning. Those are distinct, verifiable outcomes across two repositories. [S1–S4]
A core version number must not be used to imply that the separate packs content has updated everywhere. A follow-on deployment record would need to identify the installed core version and the actual pack revision or distribution path independently.
What users should do
Before changing permissions, establish what produced the error and whether the recorded evidence supports the proposed remedy. For an affected Nono setup, verify that the core build includes #1816 and that the independently installed guidance includes packs #29. Keep non-Nono explanations available when provenance is absent; do not treat failure to confirm Nono as proof that no other sandbox or operating-system boundary participated.
Status, provenance and attribution
This Technical Report is revision 1.0, published on 11 September 2026. The upstream records were reread on that date; both merges and the core release ancestry are verified in the public record. The upstream test suites were not rerun for this report, and reported test results remain attributed to their original authors.
Prepared through Hermes Labs' agentic research and engineering infrastructure under the direction of Rolando Bosch. Agents assisted with evidence synthesis and drafting; Rolando Bosch is the responsible human reviewer and approved publication. The upstream contribution records identify the relevant Hermes engineering work and its responsible human contributor. Neither an upstream merge nor a maintainer's review constitutes endorsement of this report or of Hermes's broader research.
Related
Companion contributions: Nono #1816 and Nono Packs #29 enforce complementary evidence and provenance boundaries. They are combined here to explain that relationship without counting two PRs as two independent deployments. [S1, S2]
Conceptual connection: Hermes's Applied hermeneutics and Epistemic integrity vocabulary concerns preserving observation versus inference, provenance and the evidence needed before a representation governs action. This report applies that framing editorially; the maintainers' merges do not endorse it. [S5]
Sources
- S1. Nono core PR and merge: github.com/nolabs-ai/nono/pull/1816
- S2. Nono Packs PR, provenance alternatives and validation: github.com/nolabs-ai/nono-packs/pull/29
- S3. Core v0.76.0 release: nono releases/tag/v0.76.0
- S4. Merge-to-release ancestry comparison: compare 00b4086f...v0.76.0
- S5. Hermes glossary: hermes-labs.ai/glossary