feat: add interactive network approval and domain rejection

[klassm]

When a sandboxed process requests access to a blocked host, the user is now prompted via an OS dialog to approve or deny the request. Approved hosts are allowed for the session; optionally persisted to the active profile for permanent access.

• OS-native dialogs: macOS (choose from list), Linux (notify-rust with XDG action buttons), Windows (PowerShell WPF dialog)
• Four choices: Allow once, Always allow, Deny once, Always deny
• Always allow/deny persists the decision to the profile config file
• New reject_domain config field with wildcard support (e.g. *.ad.com) takes priority over allow_domain, enabling explicit host blacklisting
• Approval is off by default; opt in via --network-approval ask, NONO_NETWORK_APPROVAL=ask, or approval_mode in config/profile

[gemini-code-assist]

Code Review

This pull request introduces a network approval feature, allowing users to interactively approve or deny network requests to unknown hosts via OS-level notifications. The implementation includes cross-platform support (Linux, macOS, Windows), a runtime-mutable host filter, and persistence logic for user decisions. I have identified several issues: the approval backend creates a new Tokio runtime on every call, which is inefficient; persistence errors are handled inconsistently; JSON manipulation in the config writer is prone to panics; and the timeout logic is missing or ignored in the notification backends.

[klassm]

All review comments done. Would be cool to have this - this makes maintaining the allow list a lot easier.

[lukehinds]

This is a really good idea @klassm - I am away this weekend, but will take a good look first thing Monday - out of interest , it might be good to rig this up to the Approval backend on linux (unless you already have), but that could be a follow up patch.

[klassm]

Great, thanks @lukehinds :-). Approval backend on linux also sounds nice - I would not do it directly, though. I don't have a Linux system, so that's hard to test :-)

[tho]

Interesting feature! One small UX thought: "allow once" might be ambiguous since it actually allows for the whole session, not just a single request. Maybe something like:

1. [Allow/Deny] once (single request)
2. [Allow/Deny] session
3. [Allow/Deny] always (persist to profile)

Also, what do you think about a dropdown with those three options plus Allow/Deny buttons instead of four (or more) separate buttons?

[klassm]

@tho I changed the buttons to distinguish between once, session and always.
For MacOS you get a dropdown, for Windows I guess as well. For Linux I did not figure out how to do that.

[klassm]

@lukehinds Did you have a chance to have a look again? 😇

[lukehinds]

hi @klassm , I have and I promise I am keeping an eye on this, its just a big change which commits a lot to the supervisor backend arch, so i need to make sure its malable to other planned changes.

[github-actions]

PR Review Summary

Size

Metric	Value
Lines added	+15116
Lines removed	-3254
Total changed	18370
Classification	Large (> 300 lines)

Affected crates

• crates/nono (core library) — careful review required. This is the security-critical sandbox primitive. A bug here bypasses OS-level isolation for every downstream user.
• crates/nono-proxy — downstream consumers depend on this crate. API or behaviour changes will affect external callers; treat any breaking change with extra scrutiny.
• crates/nono-cli — CLI changes. Verify argument parsing, flag documentation, and UX behaviour across supported platforms.
• bindings/c (C FFI) — ABI changes can silently break C callers. Confirm header and symbol compatibility.

Blast radius — Broad

This PR touches: source code,documentation,CI / build tooling,configuration / policy files

---

_{Updated automatically on each push to this PR.}